Commit graph

3 commits

Author SHA1 Message Date
克竟
755d505923 feat(web-shell): support mentions in scheduled task prompts 2026-07-09 16:51:49 +08:00
Shaojin Wen
001d20ff26
feat(scheduled-tasks): run each task in its own dedicated, named session (#6389)
* feat(scheduled-tasks): run each task in its own dedicated, named session

Scheduled tasks created through the Web Shell management page were never firing
in the daemon-only case: the durable-cron tick runs inside an active agent
session, and the Web Shell creates a session only lazily on the first prompt, so
a task created on the management page (with no chat open) had nothing ticking it.

This binds every management-page task to a dedicated session, minted at create
time and named " <task>". The task fires ONLY inside that session — its
transcript is the task's run history — instead of via the shared per-project
durable owner. A daemon-side keepalive heartbeats those sessions so the idle
reaper doesn't stop them, and a boot-time rehydration reloads them after a
restart. Archiving, deleting, or unarchiving the session disables, removes, or
re-enables the bound task (covered on both the REST and ACP surfaces).

Also adds task editing, a live next-run countdown, run history, a one-per-row
card layout, and a "run now" that executes in the task's bound session and
updates the last-run time. All resident-session management is opt-in and enabled
only by the real daemon (runQwenServe), so createServeApp embeds/tests are
unaffected.

* fix(scheduled-tasks): address code review on per-session task feature

Review fixes for #6389:

- Distinguish archive-disabled from user-disabled tasks: disableTasksForSessions
  now marks disabledByArchive; enableTasksForSessions only re-enables tasks
  carrying that flag, so a task the user deliberately disabled stays disabled
  across an archive/unarchive cycle. [Critical]
- Rehydrate task sessions concurrently with a per-session 30s timeout so one
  hung loadSession can't stall the boot sweep or leave healthy tasks dormant.
  [Critical]
- Await runScheduledTask + reload before executing the prompt in handleRunNow,
  so a record failure surfaces and the card's "last run" reflects the trigger.
  [Critical]
- Log keepalive/rehydrate read + heartbeat failures at debug instead of
  swallowing them silently, so a persistently-failing keepalive is diagnosable.
  [Critical]
- Add integration tests: deleteDaemonSessions -> removeTasksForSessions and
  unarchiveDaemonSessions -> enableTasksForSessions (guard the coupling). [Critical]
- DELETE route: single atomic updateCronTasks that captures the bound session
  and removes the task in one cycle, closing the read-then-remove TOCTOU.
- Stop the keepalive timer during shutdown (matters for embedders that don't
  process.exit) so it can't fire against a disposed bridge.
- Deduplicate DEFAULT_BUILDER: export it once from scheduledTasksSchedule and
  drop the dialog's copy so the create form and cron-reversal can't drift.
- Reject empty-string sessionId in isValidTask: a bound task with "" would
  silently run unbound under the scheduler's truthy guard.

* fix(scheduled-tasks): isolate task sessions, fix catch-up/jitter/revive

Second review round (#6389):

- Force `sessionScope: 'thread'` when minting a task's session. The daemon's
  default scope is 'single', which attaches to (reuses) the shared workspace
  session — so a second task, or a task alongside an open chat, would bind to
  the same session, rename it, land runs in the wrong transcript, and close it
  on delete. Thread scope guarantees each task an isolated session. [Critical]
- Re-seat a recurring task's schedule anchor to now when a PATCH changes its
  cron (or flips one-shot→recurring), not just on re-enable. A bound task's
  catch-up runs on every file-watch reload, so a bare cron edit to an
  expression with an already-past slot would fire immediately on save. [Critical]
- Revive a non-resident bound session from the keepalive when its heartbeat
  fails (reaper let it go while disabled/archived, now re-enabled). Covers the
  unarchive and PATCH false→true paths uniformly and retries each interval, so
  a re-enabled task actually resumes instead of showing a live countdown that
  never fires. Best-effort, timeout-bounded, non-blocking. [Critical]
- Report `nextRunAt` using the scheduler's jittered fire time
  (`nextDurableFireMs`) instead of the bare cron boundary, so the UI countdown
  lines up with the real fire (the tick offsets each fire by up to the jitter
  window) rather than expiring early and advancing prematurely.

All four are mutation-verified. The cross-daemon double-fire on bound tasks
(same session live in two schedulers) is a separate, architecturally-invasive
fix (claim-then-fire on the durable file) tracked as a follow-up.

* fix(scheduled-tasks): sync bound session name on task rename

Create names a task's session after the task (` <name>`), but a later PATCH
that renamed the task (or edited the prompt of an unnamed task) left the
session's display name stale. The PATCH route now re-applies
`updateSessionMetadata` with the task's effective label whenever that label
actually changes — a bare cron/enabled edit does not touch the session.
Best-effort: a metadata failure doesn't fail the committed schedule change.
Mutation-verified.

* fix(scheduled-tasks): mirror run sessionId on client type; clarify server wiring

Review follow-up (#6389, qqqys):

- [Medium] `DaemonScheduledTaskRun` now mirrors the daemon's `CronTaskRun`
  `sessionId?: string`, so run-attribution the wire already sends isn't silently
  dropped by the client type (not surfaced in the UI yet; passthrough cast means
  no mapping change needed).
- [Nit] Comment the `app.locals.stopScheduledTaskKeepalive` set site, noting it
  follows the same convention as `fsFactory`/`boundWorkspace`/`acpHandle` and is
  read by the run-qwen-serve shutdown path (kept the convention rather than
  diverge to a one-off return value / declaration merge).
- [Nit] Comment the outer `.catch(() => {})` on rehydrate as intentional
  defense-in-depth (the function already handles read + per-session failures).

* fix(scheduled-tasks): couple archive/enable + record manual run only on enqueue

Two [Critical] review items (#6389, gpt-5-codex):

- PATCH re-enable coupling: reject `enabled: true` on a task disabled BY
  archiving its session (`disabledByArchive`) with 409 `task_session_archived`.
  Re-enabling it here would show an enabled task with a countdown while its
  bound session stays archived and can never fire — the caller must unarchive
  the session (which clears the marker and reloads it). A user-disabled task
  (no marker) and non-enable edits are unaffected.

- Manual "run now" ordering: record the run only AFTER the prompt is enqueued,
  not before. `runTaskManually` now returns a promise that resolves on enqueue
  and rejects if the bound session can't be opened (archived/deleted), is
  superseded, or times out; the dialog awaits it before writing
  /scheduled-tasks/:id/run, so a failed session switch no longer leaves a
  phantom run in history. Runs are serialized (one pending at a time, button
  disabled) so two quick clicks can't drop a prompt on the single bound-run
  latch. Added coverage for failed session load and double-click; all new
  tests mutation-verified.

* fix(scheduled-tasks): close dormancy/orphan/overflow gaps from review

Five items from GPT-5 /review (#6389):

- [Critical] Bind tasks to sessions only when resident management is on:
  createServeApp now passes the bridge to the scheduled-task routes only when
  `manageScheduledTaskSessions` is set. Embedders that leave it off get UNBOUND
  tasks (shared-owner firing) instead of bound tasks nothing keeps resident or
  reloads (which would silently go dormant).
- [Critical] Keep the keepalive/revive loop running whenever task sessions are
  managed, not only when a reaper is active — archiving closes a task session,
  so a re-enabled one still needs reviving with the reaper disabled. Size the
  interval under the reaper window (≤ half of it) so a small idle timeout can't
  let a session be reaped before its first heartbeat.
- [Critical] Record a manual run only after the prompt is admitted: the bound
  run latch now resolves only if `sendPrompt` admitted the prompt and rejects on
  cancellation (e.g. onSubmitBefore) / failure, so a cancelled Run now no longer
  advances lastFiredAt or appends history.
- [Critical] Clamp the dialog's reload timer to the 32-bit setTimeout ceiling
  (~24.8 days) so a months-away schedule can't overflow and spin a reload loop.
- [Suggestion] Pre-check the task cap before spawning a session, so an over-cap
  create never mints an orphan task session it must roll back.

New tests (route unbound-when-no-bridge, cap-no-spawn, computeKeepaliveIntervalMs
bounds, far-future timer clamp) mutation-verified; full server suite green.

* fix(scheduled-tasks): guard catch-up double-fire, run-now hang, /run + cron edits

Four items from GPT-5 /review (#6389):

- [Critical] Bound-task catch-up could double-fire: detection ran on every
  file-watch reload and read the stale on-disk lastFiredAt, so a reload racing
  the async catch-up persist (a foreign write to the tasks file) re-detected and
  re-fired the same overdue slot. Track ids whose catch-up was DELIVERED but not
  yet persisted (`deliveredCatchUp`) and skip re-detecting them until the write
  lands; a merely-buffered-then-dropped catch-up isn't tracked, so it still
  re-detects from disk (recovery preserved).
- [Critical] "Run now" hung the full 30s switch timeout when the bound session
  was ALREADY the current, loaded one (no dep change → the consuming effect
  never re-ran). Fire the enqueue directly after loadSidebarSession resolves as
  well as from the effect; whoever runs first nulls the latch, so it runs once.
- [Critical] POST /run recorded a run with no enabled/disabledByArchive guard,
  unlike PATCH — a direct API caller could write a phantom "ran" record onto a
  paused/archived task. Return 409 task_disabled for a disabled task.
- [Suggestion] Anchor re-seat on cron edit compared the raw string, so a
  cosmetic change (`0 9 * * *` → `00 9 * * *`) dropped a pending catch-up.
  Compare the canonical (parsed) schedule instead.

(The setTimeout-overflow and keepalive-floor reports were already fixed in
2a12cba.) New tests for the first three + the cosmetic-cron case are
mutation-verified; full core scheduler + route suites green.

* fix(scheduled-tasks): block disabled-task run in UI; record manual run at admission

Two [Critical] review follow-ups (#6389):

- A disabled task could still EXECUTE from the Web Shell: the Run button was
  only gated on `runningTaskId`, so clicking it enqueued the prompt and the
  server's `/run` `task_disabled` guard merely refused the later history write —
  a real, unrecorded run. Gate `handleRunNow` and disable the button on
  `!task.enabled` too, so a disabled task's prompt is never enqueued.
- Manual run recorded only after the whole turn: the bound-run latch resolved
  via sendPrompt, which completes through waitForAcceptedPromptCompletion, so a
  long/permission-blocked run or a closed tab could execute without ever being
  recorded. Add an `onAdmitted` callback to sendPrompt (fired when the daemon
  accepts the prompt, before the turn) and resolve the manual-run latch at
  admission instead — cancellation before admission still rejects.

New dialog test (disabled task → no enqueue) mutation-verified; webui/web-shell
typecheck + existing session-action tests green.

* fix(scheduled-tasks): guard tick double-fire, cap rehydration, harden lifecycle writes

Review follow-ups (#6389):

- Extend the fire-persist re-detection guard to ON-TIME tick fires, not just
  catch-ups (renamed deliveredCatchUp → firePersistPending): a bound task fired
  by the tick advances lastFiredAt asynchronously, so a reload racing that write
  (bound detection runs every reload) could re-detect the slot and double-fire.
  The tick persist now adds its ids to the guard and clears them when the write
  lands, symmetric to the catch-up persist.
- Bound boot-rehydration concurrency (batches of 4): each loadSession forks a
  child, so loading up to 50 at once spiked the host and risked spawn failures
  that strand tasks. The keepalive revive path was already sequential.
- Archive disable failure is now logged (was fully swallowed) so a broken
  archive→pause coupling — where the keepalive would revive the just-archived
  session — is diagnosable.
- Unarchive re-enable failure is surfaced in the result `errors` and logged, and
  enableTasksForSessions also runs for already-active sessions — so a task left
  stranded ({enabled:false, disabledByArchive:true}) by a prior failed enable is
  recoverable by re-unarchiving, instead of being permanently stuck.
- Create rollback now removes the persisted session (close + removeSession), so
  the loser of a concurrent create at the cap boundary (passes the pre-check,
  loses the authoritative write) doesn't leave an orphan named session.

New tests (tick-fire guard, bounded rehydration, already-active recovery)
mutation-verified; full core scheduler + serve suites green.

* fix(scheduled-tasks): one-shot run/edit correctness; tick persist non-regression

Review follow-ups (#6389, ci-bot):

- [Critical] Manual /run on a ONE-SHOT task now removes it from the store. Its
  slot is still in the future, so stamping lastFiredAt=now didn't stop the
  scheduler firing it again at its original time — a double run. A one-shot's
  manual run IS its single fire, so the task is spent.
- [Critical] PATCH recurring:false now re-seats the one-shot's createdAt anchor.
  The old (long-past) anchor made the scheduler read it as a MISSED one-shot and
  fire + permanently delete it. Re-seating createdAt points its next fire at the
  upcoming occurrence. Also covers a cron edit on an existing one-shot.
- [Suggestion] The tick persist no longer regresses lastFiredAt: it skips the
  write when the on-disk stamp is already >= the tick slot (a concurrent manual
  /run or catch-up may have stamped newer), mirroring the catch-up persist guard.
- [Suggestion] Added the missing create-rollback test: a post-spawn commit
  failure closes AND removes the minted session (no orphan).

New tests (one-shot run removal, recurring→one-shot re-seat, rollback teardown)
mutation-verified; core scheduler + route suites green.

* fix(scheduled-tasks): ref-count fire guard, real rehydration cap, authoritative run check

Four [Critical] review follow-ups (#6389):

- Ref-count firePersistPending (was a boolean Set): the same task can have two
  lastFiredAt persists in flight (fired again before the first write landed);
  clearing on the first settle dropped the guard while the second was still
  pending, re-opening the double-fire window. The count holds it until the last
  persist settles.
- Rehydration concurrency is now enforced on the REAL loads: loadSession isn't
  abortable, so a timed-out load kept forking in the background while the next
  batch started. A bounded worker pool holds each slot until the underlying load
  actually settles, so in-flight child spawns never exceed the cap.
- Unarchive recovery reports failures for the full resume set: it enables both
  unarchived AND already-active sessions but only logged/returned errors for
  unarchived, so a failed already-active recovery surfaced errors:[] and left a
  task stranded. Deduped one list used for the call, log, and errors.
- Manual "run now" re-checks server-authoritative state before enqueuing: the
  dialog snapshot can be stale (another tab/API disabled/deleted the task), so
  it would execute the prompt and only the /run record would 409. It now
  refreshes, bails if gone/disabled, and enqueues the FRESH prompt/session.

New tests (ref-count, slot-held-past-timeout, stale-disabled re-check)
mutation-verified; core scheduler + serve + dialog suites green.

* fix(scheduled-tasks): catch-up non-regression, disabled-edit re-seat, run/timer/keepalive hardening

Review follow-ups (#6389):

- [Critical] Catch-up persist no longer regresses lastFiredAt: use `>=` like the
  tick persist, so a newer stamp (a cross-process manual /run) landing while the
  catch-up write is in flight isn't overwritten back to the older minute.
- [Critical] The PATCH anchor re-seat now runs for schedule edits even while the
  task is disabled — editing a disabled one-shot's cron then re-enabling it (two
  separate requests) no longer leaves a stale anchor that fires + deletes it.
- [High] Manual "run now" of a bound ONE-SHOT consumes it server-side (/run,
  which deletes) BEFORE enqueuing, so a record failure leaves a recoverable
  "recorded but never ran" instead of a silent double execution at its slot.
- [Medium] The dialog reload timer backs off a stuck past-due nextRunAt (fast
  reloads to catch a just-fired advance, then a slow lane) instead of spinning a
  1 Hz GET loop.
- [Medium] The manual-run latch bounds the admission phase with a timeout, so a
  send that wedges before admission degrades to a visible "run failed" instead
  of freezing the run controls.
- [Suggestion] Keepalive: an in-flight guard skips a tick while the previous
  pass runs (no duplicate concurrent loadSession spawns), and per-session
  exponential backoff stops retrying a permanently-gone session every interval.

New tests mutation-verified. Two deeper items (a task session winning the
durable lock and firing unbound tasks; tearing down a consumed one-shot's
session) are left open as tracked follow-ups — both need new daemon↔child
infrastructure.

* fix(scheduled-tasks): one-shot anchor on unarchive, memoize next-fire, sanitize + log

Review follow-ups (#6389):

- [Critical] enableTasksForSessions now re-seats a ONE-SHOT's createdAt anchor
  (not just recurring's lastFiredAt) on unarchive — otherwise unarchiving a task
  that was converted to recurring:false while disabled fires it as a missed
  one-shot and permanently deletes it.
- [Critical] Log the DELETE-path removeTasksForSessions failure (was fully
  swallowed) like the archive/unarchive paths — the session is already gone, so
  a silent write failure leaves the still-enabled bound task a permanent ghost.
- [Medium] Memoize nextDurableFireMs (deterministic per id/cron/recurring/anchor)
  — a sparse cron costs hundreds of ms per scan and the route recomputed it per
  task on every request, stalling the event loop for 50 yearly tasks.
- [Nit] The consumed one-shot /run response now nulls nextRunAt (it was
  advertising a future fire on an entity the next GET omits).
- [Suggestion] scheduledTaskSessionName strips terminal control sequences (the
  bridge title guard rejects them → silently drops the rename) and truncates on
  a code-point boundary (no lone surrogate broadcast as U+FFFD).
- [Critical/doc] Document that firePersistPending is instance-scoped — the
  narrow cross-instance restart window is an accepted edge.
- Added the missing test for editing an enabled one-shot's cron.

New tests mutation-adjacent; suites green. Two deeper items (session deleted
outside the daemon orphaning a bound task; surfacing bound tasks in cron_list)
are left open as tracked follow-ups.

* fix(scheduled-tasks): re-seat one-shot anchor on re-enable; guard duplicate revive

Two [Critical] review follow-ups (#6389):

- Re-enabling a one-shot now re-seats its createdAt anchor (added justReEnabled
  to the one-shot branch). A one-shot disabled past its slot then re-enabled was
  otherwise read as a missed one-shot on the next reload — fired immediately and
  permanently deleted. Updated the prior "leaves anchor untouched" test to the
  safe behavior (fires at next occurrence).
- Keepalive revive no longer spawns a duplicate child: loadSession isn't
  abortable, so a timed-out revive keeps running; a later tick (past its backoff)
  would start a SECOND load for the same session. An in-flight `reviving` set
  (cleared on the load's TRUE settlement, not the timeout) blocks that — without
  holding the sequential tick, so other sessions' heartbeats aren't delayed.
  Added a configurable reviveTimeoutMs for the test.

Both mutation-verified. (The one-shot /run session teardown raised again is the
same item as the open deferral — a synchronous close there would break the run,
which executes after /run; it's tracked for the keepalive orphan-sweep.)

* fix(scheduled-tasks): strip bidi override/isolate chars from session name

The bridge's title guard (hasControlCharacter) only rejects C0/DEL, so
Unicode bidi override/embedding/isolate controls (U+202A–202E, U+2066–2069)
slip past it and can visually reorder a scheduled-task session name in the
session list — a Trojan-Source-style attack (CVE-2021-42574). Strip them
alongside the existing terminal-control-sequence pass, matching core's
stripDisplayControlChars canonical set.

Adds a test built from code points so the test file itself carries no
reordering controls.

* fix(scheduled-tasks): close review findings — rehydrate deadlock, manual-run recording, shared helpers, tests

Addresses the review findings on the per-task-session work:

- keepalive rehydrate no longer awaits a non-abortable loadSession after its
  timeout. A genuinely hung load would pin its worker and, with enough hangs,
  wedge the whole boot sweep (Promise.all never settles) so later task sessions
  never rehydrated. The worker now records the timeout as failed and pulls the
  next queued session; the background load is left to settle. Rewrote the test
  that pinned the old "hold the slot" behavior into a no-wedge regression guard.
- web-shell manual run drops its pre-admission timeout. sendPrompt isn't
  abortable, so rejecting on the timer while the send was still in flight let a
  LATE admission execute an UNRECORDED run the user could retry into a
  duplicate. The run is now tied to admission (accepted prompts are always
  recorded); the "session never becomes active" phase stays bounded by the
  switch timeout in runTaskManually.
- extract collectBoundSessionIds() shared by the heartbeat + rehydrate passes
  (was duplicated) and isBoundTask() in the lifecycle module (was the lone
  `sessionId !== undefined` check vs. the strict one used everywhere else).
- spell the nextDurableFireMs cache-key separator as `\x00` rather than a
  literal NUL byte, so cronScheduler.ts no longer reads as binary to ripgrep.
- add App.test coverage for the manual-run orchestration (admission-resolve,
  cancel/error reject, immediate fire, supersede, switch timeout) and a
  keepalive test that a disabled task gets no heartbeat and no revive.

* fix(web-shell): "create via chat" opens a fresh session in scheduled tasks

The scheduled-tasks "Create via chat" button switched to the chat view but
stayed on the CURRENT session, piling the task-creation conversation onto
whatever the user was already doing. It now starts a new session first
(createNewSession) and jumps to it before priming the composer, so task
creation gets its own chat. Covered by a new App.test case asserting
clearSession() is called.

* fix(scheduled-tasks): address follow-up review findings

- keepalive rehydrate: guard the onError callback with try/catch. If it threw
  (e.g. stderr EPIPE during log rotation) the rejection escaped loadOne, failed
  its worker, and short-circuited Promise.all — stranding every other queued
  session.
- cronScheduler catch-up: use the strict `typeof sessionId === 'string' &&
  length > 0` bound-check instead of `!== undefined`, matching every other
  "is bound?" site.
- server rehydration: log the outer defense-in-depth catch instead of swallowing
  it, so an unexpected throw isn't a silent "tasks never fire".
- session-name sanitizer: also strip the standalone Bidi_Control marks U+061C /
  U+200E / U+200F, not just the override/isolate ranges.
- scheduled-tasks dialog: when a consumed one-shot then fails to deliver, show a
  specific "deleted but never ran — recreate it" error instead of the generic
  "run failed" that hid the deletion. Kept the deliberate consume-first ordering.

* fix(web-shell): don't prime the composer when "create via chat" can't start a new session

onCreateViaChat's deferred composer-priming ran unconditionally: if
createNewSession() failed, the task-starter text was dropped into the CURRENT
session (only onSessionIdChange was gated on success). Gate all post-create
side effects on `created`, matching handleMissingSessionNewSession. Adds an
App.test failure-path case (new session fails → composer not primed).

---------

Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
2026-07-07 06:22:36 +00:00
Shaojin Wen
9a63c03224
feat(web-shell): add a Scheduled Tasks management page (#6348)
* feat(web-shell): add scheduled tasks management page

Add a "Scheduled tasks" page to the Web Shell for managing durable cron tasks against the current workspace.

- Sidebar entry opens a full-pane page (replaces the chat area, not a modal) listing tasks with enable/disable toggle, delete, run-now, and human-readable schedules.
- "New scheduled task" opens a modal with a schedule builder (daily / weekdays / weekly / hourly / every-N-minutes / custom cron) and a live preview.
- "Create via chat" returns to the chat and primes the composer so the agent creates the task through its cron_create tool.
- Daemon CRUD routes (GET/POST/PATCH/DELETE /scheduled-tasks) read/write the existing per-project scheduled_tasks.json; task firing stays with the session-side scheduler.
- Extend DurableCronTask with optional name/enabled (backward compatible); the scheduler skips tasks with enabled:false.
- Add /scheduled-tasks to the vite dev-server proxy allowlist so the page works under npm run dev:daemon.

* chore(web-shell): address review feedback on scheduled tasks

- cron_list: surface name/enabled so the agent can tell a disabled durable task from an active one (a disabled task no longer looks identical to an active one).
- core: export only the tasks-file functions the daemon route actually uses (drop unused addCronTask / getCronFilePath / CRON_TASKS_DISPLAY_PATH from the public barrel).
- CronScheduler: warn when a durable reload fails and the prior view is kept, since a just-disabled or -deleted task can keep firing until the next successful reload.
- Extract the schedule helpers (buildCron / describeCron / parseHhmm / describeLastRun) into a pure module and add unit tests for them.
- Add route tests for PATCH cron/prompt/recurring, empty-patch rejection, and POST field-length / boolean-type validation.

* chore(web-shell): address second review round on scheduled tasks

- Log CRUD errors server-side (writeStderrLine) in each route catch block, matching the other daemon routes.
- Share one id generator (generateCronTaskId in cronTasksFile) between the scheduler and the daemon route instead of duplicating it.
- describeCron: recognize cron day-of-week 7 as an alternate notation for Sunday.
- Reset the builder time to :00 when switching to the hourly frequency (its time picker is hidden, so it no longer silently carries the daily minute).
- Tests: cron_list name/disabled output; route Feb-30 impossible-cron and corrupt-file 500 read-failure; describeCron dow=7.

* chore(web-shell): address third review round on scheduled tasks

- Run now: report sendPrompt rejections via the toast/error path instead of dropping the promise.
- Block chat interaction while the full-pane Scheduled Tasks view is open, so the covered composer can't receive keystrokes/Escape.
- Guard reload() with a request-sequence id so a slow load can't overwrite a newer list after a mutation.
- Re-enabling a task that had genuinely fired resumes from now instead of catching up work paused while it was disabled.
- Restrict "every N minutes" to divisors of 60 (a non-divisor */N fires more often than the label claims).
- Show a Repeats / Runs once label on each card so tool-created one-shots aren't mistaken for repeating schedules.
- Return generic 500 client messages (no internal file path); the detail is logged server-side.
- Tests: SDK scheduled-task methods (method/URL/id-encoding/headers/errors); route re-enable behavior both ways.

* chore(web-shell): address fourth review round (minor suggestions)

- Route error logs interpolate the actual task id instead of the literal ":id".
- cron_list returnDisplay includes the task name (matching llmContent) so terminal /cron list shows UI-assigned names.
- Truncate the delete-confirm label so an unnamed task's long prompt doesn't blow up the confirm() dialog.
- Cap the create-form prompt textarea at MAX_PROMPT_LENGTH and drop the dead typeof-window guard.
- Test generateCronTaskId (format + near-uniqueness).

* chore(web-shell): address fifth review round on scheduled tasks

- Re-enable now resumes any recurring task from now (stamp on every false→true), not only ones that had already fired — a task disabled before its first run no longer catch-up-fires the slot it was paused through.
- describeCron applies the same divisor-of-60 check as buildCron, so a hand-edited/persisted */45 falls back to the raw expression instead of a misleading "every 45 minutes".
- Strengthen the corrupt-file route test to assert the generic client message and no leaked file path.
- Tests: recurring-disabled-before-first-run and one-shot re-enable; describeCron non-divisor fallback.

* test(cli): cover legacy scheduled-task normalization on GET

Seed a pre-fields task (no name/enabled) directly to disk and assert the GET response normalizes it to name:null / enabled:true, guarding backward compatibility with existing scheduled_tasks.json files.

* fix(core): cap durable cron loads against a durable-only budget

The daemon route accepts up to MAX_JOBS durable tasks on disk, but the scheduler previously capped durable loads against its combined job map (session-only + durable). A session holding session-only cron jobs could push the map to MAX_JOBS and make loadFileTasks silently skip durable tasks the route had already accepted — a create that returned 201 would then never fire.

Cap durable installs against a durable-only count instead, and share one MAX_JOBS constant between the scheduler and the daemon route, so a successful create is always loadable. Adds a scheduler test that 40 session-only jobs no longer crowd out 20 durable loads.
2026-07-06 03:47:17 +00:00