feat(daemon): Support current-session scheduled tasks - #9838

Addressed the design review in 0627a51299.

The PR description was updated to match the corrected defaults and trust model. Verification: Prettier check and git diff --check pass.

Reviewed the new identifier-drift suggestion on 0627a51299. No source change or new commit was needed: the comment contrasts identical spellings, while the design already matches the current bridge-entry, REST-summary, and persisted-task identifiers. The thread has been answered and resolved. Current substantive CI checks are green; the older cancelled route runs were superseded by the latest passing run.

Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration.

Implementation is now available in 5c65b19edb.

Verification after rebasing onto origin/main@b5aec6691e:

• Core cron_create: 16/16 passed.
• ACP bridge: 124/124 passed.
• Scheduled-task routes: 102/102 passed, including the trusted active-prompt path, pending-interaction refusal, caller ownership, lifecycle, concurrency, capacity, and generation rollback coverage.
• Web Shell Scheduled Tasks dialog: 51/51 passed.
• ACP Session current-mode forwarding/older-bridge behavior: 2 targeted tests passed.
• Capability registry/server: 3 targeted tests passed.
• Primary, startup-secondary, and dynamically attached runtime callback wiring: 2 targeted tests passed.
• npm run lint passed, and git diff origin/main --check is clean.

Manual wall-clock session-switch and daemon-restart E2E has not been run yet; the PR keeps the existing #9361 keepalive/rehydration and caller-owned deletion paths unchanged, and those lifecycle consumers were audited directly.

Known inherited base issue: after the latest rebase, full npm run build and npm run typecheck stop in unchanged packages/core/src/core/contentGenerator.test.ts:776. #9676 removed countTokens from the ContentGenerator interface, while the current origin/main test still calls it. The same full build/typecheck passed on the prior base before rebasing; this PR does not modify that area.

Rebased onto origin/main@3892ca32ca and force-pushed 4693c7aa5b with an exact lease to pick up the upstream fix for the inherited contentGenerator.test.ts failure.

CI is rerunning on the new head. The remaining validation boundary is the manual wall-clock session-switch plus daemon-restart E2E already called out in the PR.

CI fix pushed in 1180fcd.

• Documented the conditional scheduled_task_session_reuse capability so the protocol registry contract is complete.
• Verified the focused contract test, repository build, typecheck, lint, formatting, diff checks, and two clean audit passes. The independent test-engineer verification also passed.
• The Web Shell visual-preview workspace-sidebar failure is identical on the PR base and head and comes from an existing mock workspace-filtering bug; PR feat(daemon): Support current-session scheduled tasks #9838 does not modify that fixture or sidebar path.

Handled review threads in this push: 0. Existing review threads remain 6/6 resolved. Fresh CI was triggered by the push.

CI fix pushed in 98d15a538f.

• Made the Web Shell capability lookup fail closed when a partial or malformed workspace snapshot omits features, instead of crashing the Scheduled Tasks page.
• Verified the formerly failing test and the complete App.test.tsx suite (540/540), repository build, typecheck, lint, changed-file Prettier check, diff checks, and two clean audit passes. Independent test-engineer reproduction and post-fix verification also passed.
• The repository-wide Web Shell format check still reports five unchanged pre-existing files; the changed file itself is correctly formatted.

Handled review threads in this push: 0. Existing review threads remain 6/6 resolved. Fresh CI was triggered by the push.

CI fix pushed in 8291f123a5.

• Updated the real qwen serve integration capability contract to include scheduled_task_session_reuse when the CLI owns the managed scheduled-task bridge callback.
• Kept registry ordering exact and corrected the nearby fixture explanation; no production behavior changed.
• Verified the formerly failing test, the complete qwen-serve-routes.test.ts suite (36/36), repository build, typecheck, lint, changed-file Prettier check, diff checks, and two clean audit passes. Independent test-engineer reproduction and post-fix verification also passed.

Handled review threads in this push: 0. Existing review threads remain 7/7 resolved. Fresh CI was triggered by the push.

Review feedback handled in 2391398086

Verification: full Web Shell App test 541/541; scheduled-task routes 105/105; focused ACP bridge, bootstrap, and dialog suites passed; repository build, typecheck, lint, Prettier/pre-commit formatting, git diff --check, and independent test-engineer post-fix audit passed. Replied to and resolved 10/10 surfaced review threads. CI is now rerunning on the pushed head.

CI failure fixed in 8ca008d370

The Ubuntu no-AK capabilities assertion could observe either the bootstrap or mounted-runtime envelope. scheduled_task_session_reuse is intentionally absent during bootstrap and present after the managed runtime mounts, so the exact baseline now normalizes only that phase-dependent tag while continuing to reject every other missing, extra, or reordered capability.

Verification: targeted capabilities test passed; full qwen-serve-routes integration file 36/36 passed; startup boundary tests 2/2 passed; repository build, typecheck, lint, Prettier/pre-commit formatting, git diff --check, and independent test-engineer verification passed. No review threads were involved in this CI-only fix (0/0).

Local real-daemon verification of #9838 — one blocker found

I built a real verification environment and ran this PR end-to-end against a live qwen serve daemon (real HTTP, real ACP child processes, real wall-clock cron firing, real Web Shell in Chromium, real daemon restart). Verified at head 8ca008d370bd52acbbe40872076b548868ebcf7c.

Verdict: needs one more fix before merge. The Web Shell entrypoint works end-to-end exactly as described. The cron_create entrypoint never succeeds on a real daemon — reviewer test-plan step 3 fails 4/4 — because the prompt id the tool sends and the prompt id the bridge checks come from two different id namespaces. A one-line change makes it pass; details and an A/B proof below.

Environment

Blocker — cron_create sessionMode:'current' always fails on a real daemon

Reproduced 4/4 on the unmodified build. The tool call ends failed, no task is persisted, and the user sees Error creating cron job: [object Object].

Root cause — two different prompt-id namespaces. I instrumented the built bridgeClient.js to dump both sides of the comparison at packages/acp-bridge/src/bridgeClient.ts:1917 (then restored it and confirmed the same failure on the pristine build):

{
  "wire_promptId":        "247614dd-56e9-46f9-bdd3-8a56ea3f455a########1",
  "entry_activePromptId": "8690bd83-e2bc-4796-8691-07457245490b",
  "entry_promptActive":   true,
  "entry_sessionId":      "247614dd-56e9-46f9-bdd3-8a56ea3f455a",
  "callerSessionId":      "247614dd-56e9-46f9-bdd3-8a56ea3f455a"
}

Connection ownership passes, promptActive is true, and the source fields are all eligible. The only failing condition is entry.activePromptId !== promptId, and it can never hold:

• packages/core/src/tools/cron-create.ts:102 sends promptIdContext.getStore().
• That store is set at packages/cli/src/acp-integration/session/Session.ts:4499 to `${sessionId}########${turn}` — the core turn counter.
• packages/acp-bridge/src/bridge.ts:8812 sets entry.activePromptId = pendingEntry.promptId, which is the daemon-minted UUID returned by POST /session/:id/prompt.

These two never coincide, so the guard at bridgeClient.ts:1917 rejects with -32602 on every call, in every configuration.

Why CI is green. Both sides are tested against an assumed literal, never against each other's real value: Session.test.ts calls the creator with promptId: 'prompt-1', cron-create.test.ts wraps in promptIdContext.run('prompt-1', …), and bridgeClient.test.ts sets entry.activePromptId to whatever the test passed in. I ran both suites locally on this head — cron-create.test.ts 16/16 and bridgeClient.test.ts 125/125 pass while the live path fails.

Candidate fix (verified). The daemon already ships its own prompt id to the child: bridge.ts:8459 builds InvocationContextV1 { sessionId, promptId } from the same promptId it later stores as activePromptId, sends it in _meta[INVOCATION_CONTEXT_META_KEY], and Session.ts:4461 binds it for the whole turn via runWithInvocationContext. So in #registerCurrentSessionScheduledTaskCreator:

-          promptId: req.promptId,
+          promptId: getInvocationContext()?.promptId ?? req.promptId,

A/B on the running daemon, same scenario, nothing else changed:

Please also add a regression test that pins the two namespaces together, rather than asserting a literal on each side independently — that is the exact seam this defect lives in.

Important — every failure of this path surfaces as [object Object]

Session.ts rethrows the raw JSON-RPC error object for any code other than -32601, and cron-create.ts:139 does error instanceof Error ? error.message : String(error). A plain {code, message} object is not an Error, so String(error) yields [object Object], which is what reaches both the user and the model:

Error creating cron job: [object Object]

Every guard the PR adds (forged session, prompt mismatch, ineligible source, busy caller, already bound) is invisible today. Wrapping the rejection with its message before rethrowing would make all of them actionable — and it is what makes the blocker above hard to diagnose in the field.

Minor — the "Current conversation" option can go stale after leaving and re-entering Scheduled Tasks

Repro (3/3): open an idle conversation → open Scheduled Tasks → New scheduled task → close both → another client starts a turn in that same conversation → reopen Scheduled Tasks → New scheduled task. The daemon reports hasActivePrompt: true and the sidebar shows the running spinner, but the selector still offers Current conversation with the "Runs are kept in a separate conversation…" hint.

This is UI-only and fails closed — I followed it through and the server refused:

POST /scheduled-tasks → 409
{"error":"The requested session is busy; wait for its active prompt or pending
interaction to finish before binding it to a task","code":"session_busy"}

Nothing was persisted. Worth noting that the guard is correct on both paths I would expect users to hit: a fresh page load while the conversation is busy, and a turn started from the Web Shell composer itself — both disable the option with "Wait for the current turn or pending interaction to finish."

What passed

The Web Shell entrypoint and the shared daemon creator are solid. Everything below was observed live, not asserted in a mock.

Web Shell form — the selector renders, defaults to Dedicated, and only sends sessionId after an explicit choice. Captured request bodies:

{"cron":"0 9 * * *","prompt":"PING_UI_DEDICATED","name":"ui-dedicated","recurring":true,"enabled":true}
{"cron":"0 9 * * *","prompt":"PING_UI_CURRENT","name":"ui-current","recurring":true,"enabled":true,
 "sessionId":"a1a30584-8319-416c-a3e3-899d6ac39e42"}

Not covered by this run

Cross-workspace mismatch on a multi-workspace daemon; PATCH rebinding; the #9415 teardown-versus-reuse race; secondary/dynamically-attached workspace runtimes (only the primary runtime was exercised); the injected-bridge negative for capability advertising (not reachable from the CLI); Windows/macOS.

{
  "wire_promptId":        "247614dd-...########1",
  "entry_activePromptId": "8690bd83-e2bc-4796-8691-07457245490b",
  "entry_promptActive":   true,
  "entry_sessionId":      "247614dd-...",
  "callerSessionId":      "247614dd-..."
}

-          promptId: req.promptId,
+          promptId: getInvocationContext()?.promptId ?? req.promptId,

{"cron":"0 9 * * *","prompt":"PING_UI_DEDICATED","name":"ui-dedicated","recurring":true,"enabled":true}
{"cron":"0 9 * * *","prompt":"PING_UI_CURRENT","name":"ui-current","recurring":true,"enabled":true,
 "sessionId":"a1a30584-8319-416c-a3e3-899d6ac39e42"}

Review feedback addressed in 16a5786bfe

Thanks @wenshao for the real-daemon A/B verification. I independently reproduced the identity mismatch and applied the narrow adapter fix.

Verification: Session tests 694/694 passed; cron-create tests 17/17 passed; the busy-session route witness passed with 409 and no persisted task; repository build, typecheck, lint, Prettier/pre-commit formatting, git diff --check, two clean diff-audit passes, and independent test-engineer verification passed.

The feedback was top-level rather than an inline review thread, so there were no GitHub threads to resolve (0/0).

Addressed the latest review on commit cf63c6e82e.

Verification: BridgeClient 126/126, Session 695/695, CronCreate 17/17, scheduled-task focused route test passed, build passed, typecheck passed, lint passed, and bundle passed. The no-AK integration run passed all feature-relevant files; the unrelated SDK tool-control file was affected by local global managed-memory request ordering and passed 30/30 with an isolated memory root.

@qwen-code /triage

@qwen-code /triage

@qwen-code /triage

Round-2 local real-daemon verification of #9838 — blocker fixed, one diagnosability gap left

I rebuilt the verification environment against the current head cf63c6e82e1144d17252e0d3a606fd99f65d87a1 and re-ran the whole thing end to end on a live qwen serve daemon (real HTTP, real spawned ACP children, real wall-clock cron firing, real Web Shell in Chromium, real daemon restart, real multi-workspace daemon).

Verdict: the round-1 blocker is genuinely fixed — LGTM to merge. cron_create(sessionMode: 'current') now succeeds on a real daemon (4/4), the full lifecycle of a tool-created binding works (9/9), and all three runtime install sites — primary, startup-secondary and dynamically attached — bind for real (6/6). One non-blocking follow-up remains: half of the rejection paths still reach the user as a bare Invalid params, and it is the same seam that hid the round-1 blocker.

Environment

1. The blocker is fixed — real two-build A/B

The identity check was not weakened to get there. I patched the built child to send a forged promptId and left everything else at head: the daemon rejected it and nothing was persisted. The adapter changed which id is sent, not whether it is checked.

2. Lifecycle of a tool-created binding — 9/9

This is coverage that was impossible before this head, because the tool entrypoint never produced a binding. Real clock, * * * * *, observed over ~7 minutes across a restart.

3. Runtime wiring — all three install sites bind for real (6/6)

Reviewer test-plan step 5 was the largest untested claim; I drove it on a two-workspace daemon and then attached a third at runtime through POST /workspaces.

4. Web Shell entrypoint — no regression

5. Local fail-closed rules

Follow-up (non-blocking) — half of the rejections still say only Invalid params

The [object Object] fix works for the daemon route's domain errors: those now carry data.errorKind/status/hint, and session_already_bound reaches the model as a full sentence. But the bridge's own guards — the ones that fire on an identity or eligibility mismatch — still reach the user with their message stripped.

Live repro, no instrumentation, a scenario a user can actually hit: a scheduled run asks to keep its own future runs in the conversation it is running in. The caller is a task-owned conversation, so the source guard correctly refuses — and this is all the user and the model get:

Error creating cron job: Invalid params

The wire tap for the same guard — driven from a scheduled_task-sourced conversation so the frames are easy to isolate — shows the daemon really does send nothing more:

OUT {"jsonrpc":"2.0","id":0,"method":"qwen/control/scheduled-task/create-current",
     "params":{"callerSessionId":"a23482c7-…","promptId":"e7d91d82-…","cron":"*/13 * * * *","prompt":"R4_SOURCED","recurring":true}}
IN  {"jsonrpc":"2.0","id":0,"error":{"code":-32602,"message":"Invalid params"}}

Root cause. withLogSafeAcpError (packages/acp-bridge/src/bridge.ts:531) replaces every outbound RequestError message with logSafeRequestErrorMessage(code) and drops any data that has no errorKind. preserveScheduledTaskCreateErrorOverAcp was added precisely to survive that filter — but only for ExistingSessionScheduledTaskCreateError. The eight RequestError.invalidParams(undefined, …) guards in handleCreateCurrentSessionScheduledTask pass no data, so all of them collapse to the same three words:

• `callerSessionId` must name a session owned by this connection
• `promptId` must be a non-empty string, `cron` …, `prompt` …, `recurring` …
• The caller session does not own the active prompt ← the exact failure of round 1
• The caller session no longer owns the active prompt
• The caller session source cannot own a scheduled task

I confirmed the prompt-mismatch case too, by forging the id: identical Invalid params. So if this regressed again, the field signal would be no better than it was in round 1.

Suggested fix (small): give those guards the same treatment as the domain errors, e.g. RequestError.invalidParams({ errorKind: 'caller_prompt_mismatch', hint: '…' }, '…') — logSafeRequestErrorData already passes errorKind/hint through, and Session.ts already renders errorKind: hint.

Test-realism note: cron-create.test.ts asserts on { code: -32602, message: 'The caller session does not own the active prompt' }. That message never reaches the child for that case — the wire value is Invalid params. The assertion is right about getErrorMessage, but it reads as if the guard text were user-visible; it is not.

For contrast, the REST/Web Shell surface does this well — the same class of rejection is rendered verbatim in the form:

The deferred UI-staleness item: deferral is reasonable

Still reproduces at head (open the form → leave → another client starts a turn → reopen: the option is still offered), and it is fail-closed with a good message: POST /scheduled-tasks returns 409 session_busy, the form renders the server's sentence, and nothing is persisted. A fresh load while busy correctly disables the option. Nothing here needs to block the merge.

Test teeth — 6 mutants on the three fix hunks

Suites at this head, run locally: bridgeClient 126/126, cron-create 17/17, scheduled-task routes 105/105, ScheduledTasksDialog 53/53, Session (targeted) 2/2.

Not covered by this run

The pending-interaction guard on the private path could not be exercised live — the engine serializes approvals, so cron_create never executes while another interaction of the same turn is pending (I drove a parallel write_file + cron_create batch and the tool simply never ran); it stays defense-in-depth. Also uncovered: the injected-bridge capability negative (not reachable from the CLI), PATCH rebinding, multiple tasks per session, the #9415 teardown-versus-reuse race, Windows/macOS.

Error creating cron job: Invalid params

OUT {"jsonrpc":"2.0","id":0,"method":"qwen/control/scheduled-task/create-current",
     "params":{"callerSessionId":"a23482c7-…","promptId":"e7d91d82-…","cron":"*/13 * * * *","prompt":"R4_SOURCED","recurring":true}}
IN  {"jsonrpc":"2.0","id":0,"error":{"code":-32602,"message":"Invalid params"}}

Thanks for the thorough round-2 verification. I independently checked the exact head and agree with the diagnosability finding: these bridge guards still call RequestError.invalidParams(undefined, ...), while the log-safe ACP wrapper strips the raw message unless structured errorKind data is present.

I am deferring this as a follow-up rather than widening #9838 again. The paths fail closed, the issue is explicitly non-blocking, and this PR has already gone through more than the repository threshold of roughly five review rounds where only Critical fixes should continue landing. The current lifecycle fix remains merge-ready; the structured error taxonomy and wire-realistic coverage should be handled separately.

@qwen-code /triage