mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-07-09 17:19:02 +00:00
5f41b166e6
/new (alias of /clear) silently did nothing when typed right after cancelling a request, for two stacked reasons: - hasBlockingBackgroundWork() gated on the registry's hasUnfinalizedTasks(), which counts cancelled-but-not-yet-finalized entries. That clause exists for the headless holdback loop (every task_started must pair with a task_notification), but /clear and session resume abort-and-reset the registry right after the gate — suppressing that very notification — so blocking on it only made the switch fail in the window between cancel and finalizeCancelled(). The gate now keys off a new BackgroundTaskRegistry.hasRunningTasks(), which counts only entries still actually executing; the headless holdback keeps using hasUnfinalizedTasks() unchanged. - When genuinely blocked, interactive mode showed only a transient debug line while non-interactive returned a proper error. Interactive now returns the same visible error message, so a blocked /clear no longer looks like a no-op. Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| acp-bridge | ||
| audio-capture | ||
| channels | ||
| chrome-extension | ||
| cli | ||
| core | ||
| cua-driver | ||
| desktop | ||
| mobile-mcp | ||
| sdk-java | ||
| sdk-python | ||
| sdk-typescript | ||
| vscode-ide-companion | ||
| web-shell | ||
| web-templates | ||
| webui | ||
| zed-extension | ||