mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-10-22 06:49:52 +00:00
* fix(sdk): size session create from the daemon session budget POST /session answers only after the daemon spawned the session's ACP child and finished its initialize handshake, but the client charged that wait to the generic 30s request deadline. The daemon bounds the handshake with --initialize-timeout-ms (10s by default, 60s on the shared E2E runners), so a slow spawn was abandoned while the daemon still completed it and channel users saw "Could not create task". Restore already sizes its deadline from the advertised limits.sessionRestoreTimeoutMs plus headroom. Apply the same derived deadline to session create and worktree reset, which spawn children for the same kind of work, and keep an explicitly configured client timeout winning. The channel-workers E2E test now also outlives the initialize budget it gives the daemon. Fixes #14584 * fix(web-shell): widen the create watchdog past the daemon handshake budget Session create now waits on the daemon's ACP handshake budget (70s by default) instead of the generic 30s request deadline, so a workspace create action costs one capability preflight plus that larger create request. The watchdog that bounds the whole action still assumed 2 x 30s and would abandon a create the SDK now deliberately allows. Raise CREATE_WATCHDOG_TIMEOUT_MS to cover preflight + create + headroom, and update the deadline tests: the create and preflight budgets are no longer equal by design, a hung create is bounded at 115s, and the SDK request timeout case needs a session delay above the new create budget. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Patrol-Run: qwen-pr-conflict/jmvdyvii4fo * fix(web-shell): size the create watchdog from the advertised session budget The SDK now sizes a session create from the daemon's advertised session budget rather than the generic 30s request deadline, so a workspace create can span a 30s capability preflight plus a 70s create request. The create watchdog was still a fixed 75s derived from the old "2 x 30s" shape, so the browser reported a create timeout on a spawn the daemon was still finishing -- the bug class the SDK change fixes, one layer up. It also reddened the required Test lane: actions.test.ts guards that the watchdog covers preflight + create + headroom, a floor that is now 115s. Derive the watchdog from the same advertised budget the restore path already reads, so the two clients stop diverging whenever a budget moves, and drop the "keep in sync with DEFAULT_FETCH_TIMEOUT_MS" comment that no longer describes where the number comes from. The guard that asserted a preflight and a create share one budget now asserts what the test is named for: the create budget is sized from the session budget, and the watchdog covers the sum plus headroom. The two neighbouring watchdog tests derive their expected deadline from the same helper instead of hardcoding 75000ms, so the next budget move does not silently re-break them. The restore and load watchdogs are untouched -- they were already derived and still sit at 75s for an old daemon. * fix(sdk): stop a short restore budget from shortening a session create `limits.sessionRestoreTimeoutMs` is the operator's restore knob, and the server returns an explicit `--session-restore-timeout-ms` verbatim with no floor -- only the `--initialize-timeout-ms` branch clamps to the default. Sizing create and worktree reset from it alone meant a legal config like `--initialize-timeout-ms 60000 --session-restore-timeout-ms 5000` gave both routes a 15s client deadline, under the 30s generic request deadline they used before this change, so a create that always worked was now abandoned. Give the two spawn routes their own resolver that floors the derived budget at the generic request deadline. Restore keeps the unfloored budget: pinning it low is deliberate, and flooring the shared helper would have raised it. The Web Shell create watchdog gets the same floor on its create half, so a short restore pin yields a 75s watchdog (30s preflight + 30s create + 15s headroom) rather than 60s, which would have re-opened the gap this PR closes. * docs(sdk): narrow the timeout claims this change falsifies Three statements described create as a short-lived 30s route and the Web Shell creation limit as a fixed 75s, which stops being true once create is sized from the advertised session budget and the watchdog is derived from it. Correct the fetchTimeoutMs option doc, the session-operation resolver's own contract (the advertised field is the restore knob, so for a spawn it hints at the handshake cost rather than bounding it, and a client that creates before reading capabilities still falls back to the 70s default), and the daemon configuration page's Web Shell deadline section -- including scoping the "--initialize-timeout-ms does not raise the create request" claim to the capability preflight, which is the only leg it still holds for. * test(e2e): defer the channel-worker deadline to main #14587 already widened this file's budgets on main (300s ceiling), so this branch's per-test comment would only have lowered it back to 120s. The client fix this PR carries is covered by the SDK and Web Shell unit tests. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Patrol-Run: qwen-pr-closeout/jmve7t0jzg8 * docs(daemon): correct the create-deadline claims and pin the new budgets R2-1: the Web Shell README section this page links to still documented the replaced 75s fixed action limit, so a host integrator sizing a create against it would tear down a spawn the daemon still completes. R1-6: qualify the initialize-timeout claim with the explicit restore pin, the 60000 floor and the un-read capabilities fallback. R2-3: pin the deliberately unfloored restore route. R2-2: pin the advertised budget reaching the create watchdog through the real call chain. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Patrol-Run: qwen-pr-closeout/jmvegdno2gr --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> |
||
|---|---|---|
| .. | ||
| assets | ||
| 00-index.md | ||
| 01-architecture.md | ||
| 02-serve-runtime.md | ||
| 03-acp-bridge.md | ||
| 04-permission-mediation.md | ||
| 05-mcp-transport-pool.md | ||
| 06-mcp-budget-guardrails.md | ||
| 07-workspace-filesystem.md | ||
| 08-session-lifecycle.md | ||
| 09-event-schema.md | ||
| 10-event-bus.md | ||
| 11-capabilities-versioning.md | ||
| 12-auth-security.md | ||
| 13-sdk-daemon-client.md | ||
| 14-cli-tui-adapter.md | ||
| 15-channel-adapters.md | ||
| 16-vscode-ide-adapter.md | ||
| 17-configuration.md | ||
| 18-error-taxonomy.md | ||
| 19-observability.md | ||
| 20-quickstart-operations.md | ||
| _meta.ts | ||