* feat(scheduled-tasks): add isolated run mode via create_sub_session tool
Introduce a new `create_sub_session` tool (daemon-only) that spawns a
fresh top-level sub-session with its own clean context and transcript.
Wire it into the cron scheduler as an `isolated` run mode so each
scheduled fire dispatches its prompt into a fresh sub-session instead
of accumulating in one shared transcript.
- Add `create_sub_session` tool with `first-turn` and `sent` completion modes
- Add `SubSessionLauncher` in cli/serve with concurrency cap, timeout, and truncation
- Extend ACP bridge `extMethod` dispatch for child→daemon sub-session requests
- Add `runMode` field (`shared`|`isolated`) to DurableCronTask, CronJob, and API types
- Add run-mode radio picker to ScheduledTasksDialog UI
- Fix AuthMessage hardcoded placeholder to use i18n key
* fix(scheduled-tasks): dispatch isolated fires daemon-side, not via the model
An `isolated` fire was relayed through the model: the fired prompt was
wrapped with an instruction to call `create_sub_session`. That tool's
default permission is `'ask'`, so under `ApprovalMode.DEFAULT` an
unattended fire reached `client.requestPermission`, found no SSE
subscriber, and was cancelled by the daemon's 5-minute permission
timeout. The task never ran, and the cancel was booked as a successful
run — the headline use case of a scheduled task was broken.
Route isolated fires straight to the daemon instead: the cron `onFire`
handler in `Session` calls the sub-session spawner directly, with no
model relay and no tool-permission gate. The prompt was already approved
when the task was created; laundering it back through the model only
re-opened that gate. `create_sub_session` keeps `'ask'` for
model-initiated calls, and the attended "Run now" button keeps its relay
(a user is present to answer the prompt).
Also fix orphan-session cleanup in the launcher. `closeSession` was
guarded only by `.catch()`, which covers an async rejection but not a
synchronous throw; because the call sits inside the launcher's own
`catch (err)` block, a sync throw escaped and replaced the real launch
error. Guard both shapes.
Tests:
- Cover isolated routing: dispatch, in-session fallback with no spawner,
missed one-shot, dispatch failure (dropped, never run inline), and
shared mode.
- Cover the orphan close, including a `closeSession` that throws.
- Replace the sent-mode concurrency test, which only asserted the slot
was eventually released (moving the release to the drain's *start*
kept it green) with one that asserts the slot is HELD while the drain
runs, plus one that asserts it is released at `turn_complete`.
* fix(scheduled-tasks): honor the caller's AbortSignal and harden the spawn boundary
Four findings from review, all in the model-initiated `create_sub_session`
path (the scheduled `isolated` dispatch reaches none of them).
`execute()` took no parameters, so it silently dropped the parent turn's
`AbortSignal`. `Session.ts` awaits `invocation.execute(signal)` without
racing the abort itself, so cancelling a turn with a `first-turn`
sub-session in flight pinned the caller's tool loop until the daemon's
5-minute ceiling. Accept the signal and return as soon as it fires.
The sub-session is deliberately NOT cancelled and deliberately KEEPS its
concurrency slot: `sendPrompt` has no abort seam, so the sub-session runs
on. Releasing its slot on cancel — as the review suggested — would let the
caller over-admit against sub-sessions that are still consuming a bridge
session and model quota.
`handleCreateSubSession` trusted the child-supplied `callerSessionId`
verbatim, and that id keys the launcher's per-caller concurrency bucket: a
fabricated id starts a fresh bucket at zero (cap evasion) and a victim's id
burns their slots (DoS). Validate it with the connection's existing
`ownsSession` seam.
Every daemon session wires a spawner, sub-sessions included, and each gets
its own cap-sized bucket — so one prompt could fan out 5ⁿ sub-sessions until
`maxSessions` ran dry. Gate nesting at one level: the launcher remembers the
sessions it spawned and refuses to spawn from them. With `callerSessionId`
now authenticated, the gate cannot be sidestepped.
Cap the prompt at 100,000 chars (matching the scheduled-task REST route) and
the display name at 200, both at the bridge trust boundary and, for the
prompt, in the tool's own validation so the model gets an actionable error.
Not changed: `create_sub_session` stays in `PermissionManager.CORE_TOOLS`.
Membership there SUBJECTS a tool to the `coreTools` allowlist; it does not
exempt it. Removing it — as the review suggested — is what would let the
tool bypass a user's allowlist, the way `agent` and `send_message` do today.
* fix(core): do not spawn a sub-session for an already-cancelled turn
`raceCancellation(spawner({…}), signal)` evaluated the spawner as an
argument, so the spawn started before the abort was ever checked. A turn
cancelled before `execute()` ran still created a sub-session on the daemon
— and it kept a concurrency slot — while the tool reported itself
cancelled.
Take a thunk instead, so the pre-abort check happens before any daemon work
is started. Track whether the spawn actually began, and say so: "cancelled
before it started, no sub-session was created" is a different fact from
"a sub-session may already have been created and is not cancelled".
Regression test asserts the spawner is never called for a pre-aborted
signal; it fails against the eager-argument form.
* fix(serve): require callerSessionId and stop misreporting an early stream close
Two findings from review.
`awaitFirstTurn`'s `'incomplete'` stopReason was unreachable. The cleanup
`finally` calls `ac.abort()` unconditionally to tear the subscription down,
so by the time the stopReason ternary read `ac.signal.aborted` it was always
true. An event stream that closed before the turn finished (bridge teardown,
WS drop) was reported as a 5-minute wall-clock `'timeout'` — indistinguishable
from a real one. Track the timer firing in its own flag.
`callerSessionId` was validated only when present. Omitting it handed the
launcher `undefined`, which minted an `anon:<uuid>` bucket — a fresh
concurrency bucket per call, so no cap — and skipped the depth-1 nesting gate
(`info.callerSessionId !== undefined && …`). Authenticating the id closed
forgery but not omission. It is now required at the bridge boundary, and
required in `CreateSubSessionInfo`, so the launcher's anonymous fallback and
the gate's presence check are both gone. Every real caller has a session id —
the tool only ever runs inside a session's turn.
* fix(serve): surface dropped fires and drain timeouts; bound sub-sessions per workspace
Three findings from review.
A dropped `isolated` scheduled fire left no trace. `debugLogger.warn` writes
nothing unless a debug log session is active, and the scheduler persists the
fire as a run before dispatch — so a nightly task could fail forever while its
history claimed it ran. It now also writes to stderr, which the daemon forwards
from the child.
A sent-mode drain that hit its 30-minute ceiling was equally silent: the catch
saw `drainAc.signal.aborted` and skipped logging, the `finally` freed the
concurrency slot, and the sub-session — which the abort does not cancel — kept
burning a bridge session and model quota. The timer now records its own firing
(the controller cannot: `finally` aborts it on every exit path) and the timeout
is written to stderr. The drain ceiling is injectable for tests, mirroring
`firstTurnTimeoutMs`.
The per-caller concurrency cap trusts `callerSessionId`, and the bridge can only
authenticate that id as "a session on this channel". Every session of a
workspace shares one child process, so nothing at the transport can prove which
of them issued the call — and a per-session secret would be readable by the
whole process anyway. Rather than pretend otherwise, add a workspace-wide
ceiling on concurrent sub-sessions that holds no matter which bucket a launch is
charged to.
* 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>
* feat(web-shell): add token-usage analytics dashboard to Daemon Status
Add a "统计 / Usage" tab to the Daemon Status page: a Today/7D/30D period toggle over the selected range's token totals and input/output/cache-read breakdown, a 12-month token heatmap (per-day tokens + cache-read tooltip, localized month labels), per-model token share, skill-call counts, and daily token/session charts.
Backend: a new read-only GET /usage/dashboard daemon API backed by a core usage-dashboard service that aggregates the durable local usage history (cross-project ~/.qwen), reusing loadUsageHistory + aggregateUsage. Skill counts are threaded through the shared usage pipeline. No new instrumentation — every metric is read from data qwen-code already persists.
* fix(web-shell): address usage-dashboard review feedback
- cap `aggregateUsage` topSkills at 25 like topTools, so the aggregate and dashboard payload stay bounded
- fix a DST drift in the heatmap grid: advance the day/month cursor by calendar day (setDate) instead of a fixed `i * MS_PER_DAY` offset
- cache the loaded history once (range-independent) so toggling Today/7D/30D re-aggregates from a single disk read; split a pure `buildUsageDashboard(records, opts)` out of `loadUsageDashboard`
- drop the unused per-day streak computation and the dead `daemon.usage.streak` i18n key
- add debug logging to the dashboard builder and a direct `aggregateUsage`-skills unit test
* fix(usage-dashboard): make the dashboard load read-only + fix cache coalescing
- Make the daemon dashboard side-effect free: `loadUsageHistory` gains a `persistRebuild` option, and the route passes `persistRebuild: false`, so serving a GET never writes to `~/.qwen`. The transcript-rebuild fallback previously persisted rebuilt records (including an in-progress session), violating the read-only contract.
- Fix cache coalescing on the slow path: a pending history load is now reused regardless of age (the TTL starts at settlement), so a request arriving after the TTL while the load is still pending no longer kicks off a second full load.
- Tests: read-only rebuild writes nothing, `metricsToUsageRecord` copies `SessionMetrics.skills`, and a pending load is shared past the TTL.
* 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.
* feat(web-shell): time-series metrics charts on Daemon Status
Add seven bottleneck-analysis line charts (concurrency, requests, API
latency, prompt latency, event-loop lag, memory, token burn) to the
Daemon Status dashboard, backed by a new server-side metrics ring.
The status endpoint is a point-in-time snapshot, so line charts need a
time series. A bounded ring buffer in the daemon (daemon-metrics-ring.ts)
seals one bucket every 5s (~15min retained) from three seams:
- HTTP request rate/latency via the telemetry middleware
- prompt queue-wait/duration via the bridge telemetry hooks
- per-round token usage sniffed at the bridge session/update fan-in
(new DaemonBridgeTelemetryMetrics.tokenUsage hook)
plus memory / active sessions+prompts / a window-scoped event-loop lag
p99 read as gauges at seal time.
The series rides the existing GET /daemon/status contract
(runtime.metrics.series), threaded through the SDK types (JSON passthrough)
to a dependency-free inline-SVG chart component in web-shell -- no charting
library added to the CSP-strict serve --web bundle.
Tests: metrics-ring math, token-usage sniffing on the real sessionUpdate
path, and SVG chart rendering. Verified end-to-end against a live daemon
(GLM-5.2): requests/latency/memory/event-loop, real token burn and prompt
duration, with the concurrency gauge tracking active prompts.
* feat(web-shell): tabs, chart tooltips, and fullscreen for Daemon Status
Split the now chart-heavy Daemon Status dashboard into Overview / Metrics /
Diagnostics tabs (status badge, refresh, and issues stay global) so
monitoring, configuration, and troubleshooting each get their own space
instead of one long 70vh scroll.
Add an interactive hover cursor to the charts: a vertical time line, a dot on
each series, and a tooltip reading the bucket time plus every series' value at
that point -- previously only the latest value and peak were legible, from the
legend.
Add an opt-in fullscreen toggle to DialogShell (via allowFullscreen, wired for
Daemon Status) that expands the panel to near the full viewport; scrolling is
consolidated into the shell body so the content actually grows with it.
Tests: tab switching + diagnostics-behind-tab, SVG tooltip rendering, and the
DialogShell fullscreen toggle. Verified end-to-end against a live daemon
(GLM-5.2) with real request / token / prompt data.
* feat(web-shell): add CPU, LLM-latency, queue-depth, IPC & connection metrics
Extend the Daemon Status metrics ring with more bottleneck-analysis
dimensions, filling the two biggest gaps — resource cost had only memory
(no CPU), and latency had only client->daemon HTTP (not daemon->model):
- CPU %: process.cpuUsage() delta, core-normalized (memoryPressureMonitor
formula, clamped 0-100), sampled alongside memory.
- LLM API latency p50/p95: the token frame's _meta.durationMs (the
daemon->model round-trip), separating 'model is slow' from 'we are slow'.
- Prompt queue depth: a new bridge.pendingPromptTotal aggregate, folded into
the concurrency chart beside active tasks.
- IPC pipe throughput: daemon<->ACP-child stdio bytes (already measured; now
windowed via metricsRing.recordPipe).
- Connection counts (SSE/WS/ACP) and rate-limit rejections, read lazily in the
sampler from the ACP handle registry and the rate limiter.
The tokenUsage telemetry hook is widened to carry durationMs. Verified
end-to-end against a live daemon (GLM-5.2): LLM p95 28.6s vs HTTP p95 324ms,
queue depth 1, IPC peak 0.3MB, SSE gauge 1 on a live stream.
* feat(web-shell): add ACP child process CPU/memory (self-reported over ACP)
The daemon's own CPU/memory only tell half the story — the real LLM/tool work
runs in the spawned 'qwen --acp' child, which is where the resource cost lives.
Surface it: the child self-reports its rss + cpuPercent to the daemon over a new
read-only ACP extMethod (qwen/status/workspace/resource); the bridge caches the
latest sample on the live channel, and the metrics sampler reads it
synchronously each tick (firing an async refresh for the next, off the hot path).
The child computes cpuPercent as a process.cpuUsage() delta between polls (no
dependency on MemoryPressureMonitor's tool-gated sampling), core-normalized and
clamped. Rendered as a second line on the CPU and Memory charts (daemon vs
child, side by side).
Verified end-to-end (GLM-5.2): child RSS ~300MB vs daemon RSS ~225MB, child CPU
tracking above the daemon's -- the child is the resource hog, now visible.
* test(web-shell): cover Metrics tab, chart rendering, and the recordRequest seam
Address review — the metrics dashboard's rendering and its HTTP data seam had
no tests:
- DaemonStatusDialog: switching to the Metrics tab renders the charts from the
series (one SvgLineChart per card) and hides the Overview panel; an empty
series shows the collecting-metrics placeholder.
- daemonTelemetryMiddleware: recordRequest fires once with (durationMs,
statusCode) on a matched route (real status code; once across finish/close),
is not called for unmatched routes, and is a silent no-op when omitted.
* fix(web-shell): enlarge Daemon Status charts in fullscreen
Fullscreen widened the panel but the charts stayed small — the grid just packed
in more 280px cards at a fixed 52px SVG height, so the extra viewport bought
more small charts, not bigger ones. Now the DialogShell body carries a
`data-dialog-fullscreen` marker; the chart grid switches to wider cards (min
480px → fewer columns) and the SVG grows to 120px, so fullscreen actually
enlarges the plots. Verified: 2 wide columns at 120px vs 3-4 columns at 52px.
* fix(web-shell): resolve chart colors in portal, guard child-resource polling
Address review (real-user + ci-bot):
- [Critical] Chart colors (--primary, --agent-blue-400) resolved to nothing in
the DialogShell portal (createPortal to document.body escapes the app root that
defines them), so ~half the chart lines rendered stroke:none. Add both vars to
DialogShell's own theme scope. Verified: 25/25 path strokes colored (was 5 none).
- [Critical] refreshChildResource had no in-flight guard; requestWorkspaceStatus
waits up to 10s (> the 5s cadence), so a degraded child accumulated concurrent
polls. Add a single-flight guard.
- [Critical] getChildResourceSnapshot returned last-good rss/cpu forever; add a
30s staleness window so a stuck child reads 0 instead of looking healthy.
- Exclude GET /daemon/status (the dashboard's own poll) from the metrics-ring
request rate, so the Requests chart doesn't count itself.
- Fix cpuPercent JSDoc (percent of total capacity across cores, clamped [0,100])
in the ring + SDK mirror; add a keep-in-sync cross-reference on the mirror.
Tests: recordRequest excludes /daemon/status; buildDaemonStatusResponse embeds
runtime.metrics.series when provided and omits it otherwise.
* fix(web-shell): address Daemon Status charts review feedback
Correctness fixes surfaced in review:
- bridgeClient: guard token accounting on a live `entry`. On the
`session/load` path HistoryReplayer re-emits saved usage as live
session/update frames before the session entry is registered, which
otherwise dumped a session's historical token total into the current
metrics window as a phantom burn spike with no model call.
- run-qwen-serve metrics sampler: wrap each tick in try/catch/finally so a
throwing getter can't crash the daemon; reset the event-loop-lag histogram
in finally so a thrown tick can't permanently discard it; skip the CPU
delta (and leave the baseline untouched) when process.cpuUsage() throws;
seed the rate-reject baseline on the first tick instead of reporting the
whole since-start backlog as one spike.
- acpAgent workspaceResource: advance the child-CPU baseline only on a
successful read, avoiding a ~2x phantom spike on the poll after a failure.
- bridge.pendingPromptTotal: count only queued prompts (state === 'queued'),
not the running one, so the "Queued" chart reflects real backpressure and
no longer shadows the "Active tasks" line.
- Make the new Daemon Status bridge hooks optional in AcpSessionBridge and
optional-chain them in the sampler, so a bridge injected via
RunQwenServeDeps.bridge that predates them degrades gracefully.
Robustness / UX:
- daemon-metrics-ring sanitizes non-finite gauges to 0 so a bad reading
never serializes as JSON null and gaps the chart.
- child-resource refresh logs failures at debug for observability.
- formatBytes drops to KB/B for sub-MB pipe traffic (was "0.0 MB").
- SvgLineChart peak label is now i18n'd (daemon.charts.peak).
- Daemon Status tabs get the full WAI-ARIA tabs pattern: aria-controls,
role=tabpanel, and Arrow/Home/End keyboard navigation with roving tabindex.
Tests: replay token guard (no live entry), pipe/gauge/sample-cap defenses,
large-value legend formatting, and tab keyboard navigation.
* fix(web-shell): keep Daemon Status fullscreen + tooltip correct in dialog portal
Two DialogShell-portal theme-scope issues surfaced by a follow-up review:
- Fullscreen was clamped back to 80vh on narrow screens: the
`@media (max-width: 560px)` `.panel` rule has equal specificity and later
source order than the base `.panelFullscreen`, so it won. Add a media-scoped
`.panelFullscreen` override so fullscreen actually expands on mobile.
- SvgLineChart tooltip background used `var(--popover, var(--card))`, neither of
which the portal theme scope defines, so the declaration dropped and the
tooltip rendered transparent over the chart. Fall back to `--background`
(which the dialog scope does define).
* fix(web-shell): flip chart tooltip below cursor near scroll-container top
The Daemon Status charts live inside DialogShell's overflow-y:auto body, so the
topmost chart's upward tooltip (bottom: calc(100% + 4px)) clipped against the
scroll container's top edge, truncating the time header / first series row on
hover. SvgLineChart now resolves its nearest scroll parent and flips the tooltip
below the cursor when the plot sits within ~one tooltip-height of that clip
boundary.
* fix(daemon-status): harden child-resource CPU/memory + sampler lag on failure
Follow-up review fixes:
- acpAgent: prevChildCpu inits to null (not {0,0}) and the workspaceResource
handler gates the delta on a live prevCpu baseline, so an init-time
cpuUsage() failure no longer manufactures a phantom spike on the first poll
— mirrors the daemon sampler's safeCpuUsage null-on-failure contract.
- acpAgent: guard process.memoryUsage() too, reporting 0 rss on failure while
keeping the already-computed cpuPercent instead of throwing the handler.
- bridge: require Number.isFinite() (typeof NaN === 'number' is true) and
clamp cpuPercent to [0,100] when caching the child's self-report.
- run-qwen-serve sampler: gate the 5s child-resource refresh on an active
SSE/WS client (idle staleness already reads 0), and hoist the event-loop
lag read before the try so a thrown tick charts the real accumulated lag
instead of a misleading 0.
* fix(daemon-status): protect artifact path from metrics callback + share CPU delta
Follow-up review fixes:
- bridgeClient: wrap recordLiveTokenUsage in try/catch so a throwing injected
onTokenUsage callback can't skip the critical artifact processing after it —
metrics are optional, artifacts are not.
- Extract computeCpuPercent() into daemon-metrics-ring and share it between the
daemon self-sampler and the ACP child's workspaceResource handler, removing
the duplicated delta/normalize/clamp math and giving it direct unit coverage
(null sample, non-positive window, normalization, phantom-spike + negative
clamps).
- Add a single-flight test for bridge.refreshChildResource (two rapid calls
collapse to one in-flight RPC).
* fix(web-shell): keep skill slash commands after starting a new session
Starting a new session (the sidebar button, quick action, and the /new,
/reset and /clear commands all route through clearSession) ran
getConnectionAfterSessionClear, which deleted connection.commands and
connection.skills. Nothing repopulated them: the SSE loop returns early on
manualSessionClear and the deferred skill-fetch path never re-runs, so before
the new session's first prompt the composer fell back to the hardcoded local
command list. That list omits skills, so typing "/rev" and pressing Tab would
not complete "/review".
Preserve the workspace-scoped commands and skills across a clear (skills,
custom, MCP-prompt and workflow slash commands all live at the workspace/config
level, not the session), and only drop the session-scoped supportedCommands and
context snapshots. This keeps skill-backed slash commands autocompleting in the
new deferred session before its first prompt — the same guarantee #6153 added
for the initial deferred connect — while still forcing the next session to
refetch fresh metadata. The next session's available_commands_update refreshes
the list once it lands.
* fix(web-shell): treat a fulfilled empty command snapshot as authoritative
Address review feedback on the new-session command fix. Preserving commands
across a clear means a later refresh must be able to clear them again when the
workspace command list genuinely shrinks to empty, otherwise the preserved
entries would keep autocompleting forever.
Both refresh paths previously kept the previous list on an empty result
(`commands.length > 0 ? commands : current.commands`):
- The streamed available_commands_update handler now assigns the mapped
commands directly, matching how skills were already handled — the daemon
snapshot is authoritative.
- The post-attach supported-commands assignment now falls back to the
preserved list only when the fetch was skipped or failed
(supportedCommands === undefined), not when it returned an empty list.
Add tests: an available_commands_update that empties the list clears stale
commands; a fulfilled-empty supported-commands fetch after a clear drops the
preserved commands; and getConnectionAfterSessionClear is exercised with the
commands/skills fields already absent.
* test(web-shell): cover supported-commands fetch failure after a clear
Add error-path coverage for the post-attach command assignment: when the
new session's supportedCommands() rejects, supportedCommands stays undefined
and the commands preserved across the clear must survive rather than being
wiped. Complements the fulfilled-empty test, which locks that a successful
empty snapshot is instead treated as authoritative.
Add an Archive quick action and a "..." overflow menu (Rename / Archive / Delete) to each session row in the web-shell sidebar, plus a collapsible "Archived" section that lazily lists archived sessions with Restore / Delete. Thread the daemon's existing archiveState filter and archive/unarchive endpoints through the webui workspace facade and the useDaemonSessions hook; rename stays limited to the current live session.
* feat(web-shell): add a daemon status page backed by GET /daemon/status
Surface the consolidated daemon status API (#5174) in the Web Shell as a
dashboard dialog opened from a sidebar footer button.
- @qwen-code/sdk: DaemonClient.daemonStatus(detail) plus DaemonStatusReport*
wire types for the /daemon/status envelope (summary and full detail).
- @qwen-code/webui: loadDaemonStatus workspace action and a
useDaemonStatusReport hook (exported as useDaemonStatus from
daemon-react-sdk).
- web-shell: DaemonStatusDialog rendering one dashboard — overall status
badge, issues list, daemon/runtime/transport/security/limits/capabilities
cards, plus per-session, workspace-diagnostics, and auth sections. The
daemon's summary/full cost split is hidden from the operator rather than
exposed as a toggle: the cheap summary rides a 5s auto-refresh while the
expensive full report (which may spawn the ACP child and aggregate
workspace diagnostics) is fetched only on open and on manual refresh, so
parking the dialog open never rehits that path. Capabilities are sorted,
counted, and height-capped; the long workspace path stays on one line,
front-truncated so the tail remains visible. New pulse-icon sidebar entry;
EN/zh-CN strings.
- vite dev proxy: forward /daemon to the daemon; without it the SPA fallback
answered /daemon/status with index.html and the dialog failed JSON parsing
under npm run dev:daemon.
* fix(web-shell): address review on the daemon status dashboard
- Drive the status badge and issues list off the full report when it is
available, not the summary. The daemon only rolls workspace/preflight/MCP
problems into status+issues for detail=full, so the summary can read "ok"
with no issues while a loaded full report is degraded — the dashboard now
reflects the full rollup (live counters still come from the summary).
- Guard the 5s poll with an in-flight ref so a slow/degraded daemon cannot
accumulate overlapping status calls (useDaemonResource discards stale
completions but does not abort; the client timeout is 30s).
- Fix the public DaemonStatusReport wire type: runtime.channelWorker.channels
is string[] (ChannelWorkerSnapshot), not an array of objects; mirror the
remaining optional snapshot fields.
* fix(web-shell): translate workspace section status badges
WorkspaceSectionRow rendered the raw wire status (`ok`/`warning`/`error`/
`unavailable`) while every other badge in the dialog goes through `t()`, so
under a Chinese UI these badges showed lowercase English. Route the badge
through `t('daemon.level.<status>')` and add the missing `daemon.level.unavailable`
key to both dictionaries.
* fix(web-shell): scope toolbar error to summary; broaden dashboard test coverage
- The toolbar "failed to load" banner now keys on the summary fetch only. A
failed full fetch is already surfaced in the diagnostics section, so it no
longer makes an otherwise-healthy summary (fresh cards + timestamp) read as
broken.
- Use the ASCII "..." ellipsis in the diagnostics-loading string to match the
rest of the i18n dictionary.
- Add tests: summary-healthy/full-failed degraded state, the ACP-disabled
transport branch, uptime/memory/duration formatting across unit boundaries
(day, GB, sub-second, fractional-second), and sidebar Daemon Status button
click (expanded + collapsed) — the feature's only entry point.
* fix(web-shell): pause polling on hidden tab; scope dev proxy; fix test mock
- Skip the 5s status poll while document.hidden, matching the sidebar poll —
a backgrounded tab no longer hits the daemon every 5s.
- Narrow the vite dev proxy to the exact /daemon/status route instead of a
bare /daemon prefix, mirroring the scoped /voice/stream entry; verified the
dashboard still proxies (summary + detail=full) in dev.
- Add a message field to the DaemonStatusReport issue mock in the webui
provider test so it matches the required DaemonStatusReportIssue shape.
* feat(web-shell): surface runtime/channel-worker diagnostics; a11y + polish
Address the daemon-status review round:
- Render the runtime startup/failure state (runtime.loading / runtime.error)
in the Runtime card so the plausible-looking zero counters during startup
are not mistaken for a healthy idle daemon.
- Surface channel-worker diagnostics (state, exit code/signal, error, restart
count) when the worker is enabled — these fields were fetched and typed but
never shown, leaving a bare "down" with no context.
- Include full.error.message in the diagnostics-failure line (matching the
summary error path) so a failed detail fetch is actionable.
- Show "N/A" instead of a literal "null" chip for null workspace summary
values (the wire type allows null).
- Add role="status" + aria-label to the health badge for screen readers.
- Rename the public hook alias useDaemonStatus -> useStatusReport, matching
the Daemon-prefix-stripping convention of the other re-exports.
- Add tests: runtime startup/failure, channel-worker diagnostics, and the
empty/disabled placeholders (sessions, rate limit, capabilities, ACP),
toolbar-banner-with-data, and pure-loading branches.
* fix(web-shell): contain daemon status crashes; workspace empty-state
- Wrap the dashboard in a local ErrorBoundary so a malformed/partial daemon
response (e.g. an older daemon omitting an additive field like
channelWorker) — most likely exactly when the daemon is sick and the
dashboard is most needed — shows a contained fallback instead of throwing
to the root boundary and white-screening the whole web shell.
- Add an empty-state to the Workspace Diagnostics card (parity with the
Sessions card) for when full.workspace is empty.
- Tests: error-boundary containment on a malformed report, and the workspace
empty-state.
* fix(web-shell): fix error-boundary recovery; contain detail crashes
Address the review round (one Critical):
- ErrorBoundary recovery was broken: the comment claimed resetKeys cleared the
fallback, but none was passed. Switch to a function-form fallback that
surfaces the actual render error (distinct from a network failure) and fix
the comment — recovery happens on re-open, since the parent only mounts the
dialog while open.
- Wrap FullDetail in its own ErrorBoundary so a malformed detail=full payload
is contained to the detail region instead of taking down the healthy summary
cards with it; add a catch-all branch so a fetch that resolves without a
`full` section shows a failed state instead of hanging on "Loading...".
- Toolbar failure banner now shows only when the summary errored AND still has
data on screen (`summary.error && summary.report`), so it no longer
misrepresents a dashboard that is rendering from the full fallback.
- SDK type: drop `& Record<string, unknown>` on DaemonStatusReport.daemon and
add the typed optional `startup` field, matching the DaemonCapabilities
convention the interface JSDoc claims.
- Add a real useDaemonStatusReport hook test asserting the `report` alias maps
from `data` — the dialog test mocks the whole hook, so nothing else guarded
it.
* feat(web-shell): surface runtime.activity in the daemon status dashboard
PR #6270 added a runtime.activity sub-object to GET /daemon/status
(activePrompts, lastActivityAt, idleSinceMs). Type it as an additive optional
on the SDK DaemonStatusReport and render it in the Runtime card: active-prompt
count and an idle duration ("no activity yet" when the daemon has seen none).
Gated on the field's presence so older daemons that omit it still render.
Verified end-to-end against a real qwen serve --web that emits the field.
* fix(web-shell): daemon status polish — i18n count, negative clamp, coverage
Address the review round (all minor):
- Move the capabilities count into the i18n string (daemon.capabilities.titleCount
with a {count} placeholder) so locales can reorder it.
- Clamp negative durations in formatDurationMs (clock-skew defense).
- Re-export the hook options type as StatusReportOptions for consumers wrapping
useStatusReport.
- Tests: use the real rate-limit tier keys (prompt/mutation/read) in the fixture,
and cover the session-id display fallback, the channel-worker signal branch,
and a healthy workspace section's chip/status rendering.
* feat(web-shell): name the failing checks behind a workspace section status
A "warning"/"error" workspace-diagnostics section only showed a rollup badge
plus count chips, so e.g. a warning preflight was opaque — the operator
couldn't tell it was the auth check without curling the API. Extract the
individual warning/error cells from the section's raw data (across cells /
servers / skills / tools / providers / hooks / extensions) and render each with
its label and message (e.g. "auth: No auth method configured."). OK and other
non-problem cells stay hidden. Verified end-to-end: a real daemon with no
credentials now shows the auth warning inline under preflight.
* fix(web-shell): cut mobile session-switch jank (P0)
- MessageList: wrap in memo and gate the O(transcript) session-timeline
signature/entries computation behind rail visibility (container >=
1160px, never true on mobile), so scroll frames and unrelated App
renders no longer rebuild a transcript-sized string
- DaemonSessionProvider: dispatch the replay snapshot before the
providers/commands/context fetches so the transcript paints one
metadata round-trip earlier on session switch; keep catchingUp
cleared once the replay is injected
Refs #6181
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* test(webui): cover replay resume catchingUp state
* test(webui): assert catchingUp replay state sequence
* fix(web-shell): restore timeline observer bootstrap
---------
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
* fix(web-shell): show skill slash commands (e.g. /review) before first prompt
Since session creation is deferred until the first prompt (#6066), the
deferred connect path reported 'connected' but only fetched workspace
providers — it never populated the slash-command list. Before sending a
message the composer therefore fell back to the hardcoded local command
list, which omits skills, so '/rev' would not autocomplete '/review'.
Fetch the session-less /workspace/skills status alongside providers in the
deferred connect path and seed connection.commands/skills from it, so
skill-backed slash commands autocomplete immediately. The full
session-scoped supported-commands snapshot (which also carries custom,
MCP-prompt and workflow commands) still replaces this once the first
prompt creates a session.
* test(web-shell): cover deferred workspace skills fetch failure
Add a parallel test to the deferred-connect warn coverage: when
client.workspaceSkills() rejects, the connection still reports
'connected' (skills are non-blocking) and the failure is logged via
console.warn, mirroring the existing workspaceProviders-failure test.
Addresses review feedback on #6153.
Multiple UI components displayed executionSummary.totalTokens (cumulative
sum of total_tokens across all API rounds) as the subagent token count.
For a subagent making 87 requests with ~51K prompt each, this inflated
to 4.4M — misleading users into thinking it was context window usage.
Switch all subagent token displays to use outputTokens (what the model
actually generated), aligning with the loading indicator which already
correctly shows output tokens only.
Closes#5683
* feat(web-shell): browse MCP server resources in the /mcp dialog
Port the TUI's MCP resource browser (#5544/#5635) to the Web Shell. The
/mcp dialog now shows per-server resource and prompt counts plus an
expandable resource browser (URI, MIME type, size, description, and the
@server:uri chat reference), reaching parity with the terminal UI.
Resources and prompts were never serialized past the in-process core
registries, so this wires the data end to end: per-server resourceCount
and promptCount ride the existing /workspace/mcp status, and a new
qwen/status/workspace/mcp/resources ext-method (mirroring the tools
drill-down) carries the resource list through the daemon, SDK, and webui
hook into the Web Shell McpDialog. All additions are protocol-additive;
older daemons 404 the new route and the client degrades gracefully.
* fix(web-shell): make resourcesByServer optional and pluralize 1-byte size
Address review on #5879:
- SerializedMcpStatusMessage.resourcesByServer is now optional, matching
its JSDoc ("older clients omit it") so TypeScript enforces the `?? {}`
defensive read at every consumer.
- mcp.resource.bytes now pluralizes ("1 byte" vs "2 bytes"), consistent
with the mcp.resourceCount / mcp.promptCount strings in this PR.
* fix(web-shell): address MCP resources review — remove non-functional @ref, harden fallbacks, add tests
Address review on #5879:
- [Critical] Remove the "@server:uri" chat-reference UI from the resource
browser: the Web Shell submits prompts as a plain text block and the
daemon forwards it verbatim (the TUI's atCommandProcessor resolution is
TUI-client-side only), so the reference never injected resource content.
The browser stays as read-only metadata; @-reference injection is a
follow-up that needs the resolver wired into the Web Shell prompt path.
- [Critical] reloadServer now isolates the resource refetch in its own
try/catch so a failed resource load can't report a successful
reconnect/enable as failed.
- [Critical] resolveServerMcpResources/Prompts skip a throwing session in
the pool-mode fallback so one degraded session can't blank the base
/workspace/mcp status (which now carries the counts).
- [Suggestion] Resource section renders an "unavailable" state when a
server advertises a count but the drill-down list is empty.
- [Suggestion] Add SDK client URL-encoding test (workspaceMcpResources),
route-table matching test, and an unconfigured-server error-branch test.
---------
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
When a user deletes a running session via the session list, the
server publishes session_closed with reason client_close on SSE.
Previously, the reconnect loop treated this as a passive disconnect
and called createOrAttach(), auto-creating a new session and
undoing the user's delete.
Now the provider detects session_closed with reason client_close,
aborts in-flight prompts, clears the session, and exits the
reconnect loop. Other reasons (idle_timeout, last_client_detached)
and session_died events fall through to the normal reconnect path.
Co-authored-by: Qwen Code <noreply@alibaba-inc.com>
* refactor(tools): rename TodoWrite tool display name to TodoList
Rename the todo tool's user-facing display name from "TodoWrite" to "TodoList" across every surface that shows it, keeping the wire/schema name `todo_write` unchanged (model tool calls and existing configs are unaffected).
- core: ToolDisplayNames.TODO_WRITE -> 'TodoList'; add a ToolDisplayNamesMigration alias so coreTools/excludeTools configs referencing the old 'TodoWrite' display name keep resolving.
- cli i18n: rename the toolDisplayName.* locale keys (en/zh/zh-TW) so the localized TUI badge stays correct.
- web-shell / webui: map the todo tool to 'TodoList' in their display layers.
- sdk daemon normalizer: the ACP plan-update path minted toolName 'TodoWrite'; emit the wire name 'todo_write' instead, so the web-shell's existing wire-name-keyed display + i18n render 'TodoList' (zh 任务清单) for plan-routed todos.
desktop keeps 'TodoWrite' as an internal tool identifier (humanized to 'Updating Tasks' / 'Todo List Updated' for users, never shown raw).
* refactor(tools): complete TodoList rename in permission rules, importer, export, examples
Address review feedback on #5319 — three display surfaces still referenced the old name, plus a few non-user-facing spots.
- permissions/rule-parser.ts: add `TodoList` to TOOL_NAME_ALIASES so `allow: ["TodoList"]` resolves (legacy `TodoWrite` kept); rename CANONICAL_TO_RULE_DISPLAY + DISPLAY_NAME_TO_VERB to TodoList. Mirrors the existing Task->Agent handling. Without this a permission rule typed with the new UI label silently did nothing.
- webui selectors.ts: also recognize the `todo_write` wire name (the daemon plan path now emits it) so todo detection no longer relies solely on the toolKind fallback.
- cli export (collect.ts): exported tool-call title TodoWrite -> TodoList (kind discriminator unchanged).
- extension/claude-converter.ts: map Claude's TodoWrite -> qwen TodoList.
- example agent templates + webui stories + integration HTML export: update the displayed name.
- test: resolveToolName('TodoList') and legacy 'TodoWrite' both -> todo_write.
desktop keeps 'TodoWrite' as an internal id (humanized to 'Updating Tasks'/'Todo List Updated' for users); deferred as noted in the PR description.
* fix(daemon): centralize mid-turn event constant + recover timed-out drains
Follow-up to #5175 addressing two post-merge /review suggestions.
Centralize the `mid_turn_message_injected` SSE event `type`: it was a bare
literal in the daemon publisher (acp-bridge), the SDK validator/reducer, and the
browser consumer (webui), so a rename in one could silently break browser-side
dedup. It now lives once in acp-bridge's dependency-free `daemonEventTypes`
module (lightweight like `mcpTimeouts`, so the SDK re-exports it via its
build-time devDep without dragging acp-bridge's type graph into the SDK bundle),
and bridgeClient / the SDK / webui all import the single binding.
Close the drain-timeout message-loss window: the daemon splices + SSE-publishes
(browser dedupes) before the ACP child's response lands, so if the child's 2s
drain timeout fires first, the late response was discarded — losing the messages
from both queues (silent, one-turn loss). The child now recovers that late
response and injects it on the next batch instead of dropping it.
Tests: drain-timeout recovery (Session), and a rename-safety assertion pinning
the shared event constant to the wire literal.
* fix(daemon): address review — log drain recovery + rename buildMidTurnParts
- Emit a `debugLogger.debug` line when a timed-out drain is recovered (session
id + count), guarded on a non-empty payload, so the recovery path is
correlatable in production logs.
- Rename `#formatMidTurnParts` → `#buildMidTurnParts`: the method records to the
chat transcript, so a "format" verb understated its side effect.
* fix(webui): release completed prompts before acceptance returns
* fix(webui): address review — comment ordering invariant and add error path test
Add a comment explaining why settledPrompts must be checked before
activePrompts in waitForAcceptedPromptCompletion (the turn event frees
the active slot, so checking activePrompts first would find the next
prompt's controller and incorrectly reject).
Add a test for turn_error arriving before acceptance returns, verifying
that sendPrompt rejects with the expected error from the settled cache.
* fix(webui): preserve prompt status across late acceptance
* chore(webui): rename prompt settled key helper
* fix(webui): guard cancel prompt status cleanup
---------
Co-authored-by: ytahdn <ytahdn@gmail.com>
