diff options
| author | Adam Malczewski <[email protected]> | 2026-05-29 18:45:45 +0900 |
|---|---|---|
| committer | Adam Malczewski <[email protected]> | 2026-05-29 18:45:45 +0900 |
| commit | dcbc51e22dcd3d7b5a01d6c3b7b0285efa49bca4 (patch) | |
| tree | 72e1a635662ed20deaee1f0b01408a5954445b26 /wishlist.md | |
| parent | 5b3e1ac64681e233f35e1b4d2230d9988667c37e (diff) | |
| download | dispatch-dcbc51e22dcd3d7b5a01d6c3b7b0285efa49bca4.tar.gz dispatch-dcbc51e22dcd3d7b5a01d6c3b7b0285efa49bca4.zip | |
feat: stop generation button with abort signal plumbing
- Add POST /chat/stop endpoint on API
- Thread abortSignal from agent-manager through Agent.run() to streamText
- Thread abortSignal option through the Agent.run() signature
- Emit status:idle on stopTab() so frontend WS gets the update
- Add stopGeneration() store method on frontend tabStore
- Add stop button in ChatInput (btn-sm lg:btn-xs for mobile tap target)
- Add tests for /chat/stop endpoint
- Refactor processMessage to pass abortSignal to agent.run
Diffstat (limited to 'wishlist.md')
| -rw-r--r-- | wishlist.md | 7 |
1 files changed, 3 insertions, 4 deletions
diff --git a/wishlist.md b/wishlist.md index b5eb60f..f896dc0 100644 --- a/wishlist.md +++ b/wishlist.md @@ -19,7 +19,6 @@ - **ntfy push notifications.** Configurable ntfy.sh notifications — ping on chat completion, errors, permission prompts, and other events. Configure topic URL and which events trigger notifications. -- **Failed tool calls should produce proper tool results, not get silently dropped.** - - Repro: agent calls `read_file` but the tool is unavailable → SDK emits `tried to call unavailable tool`. User grants permission and asks agent to retry. Agent tries again, but the SDK now errors with `Tool results are missing for tool calls call_00_..., call_01_...` — the previous step's tool calls were recorded (IDs registered in the assistant message) but their results were never written (because the stream aborted when the unavailable-tool error was caught). The synthetic error path in agent.ts (lines 856-882) only covers the ONE tool that triggered the error; sibling tool calls in the same batch that the LLM sent alongside the unavailable one have their IDs in the history but no matching tool-result, which trips the v6 SDK validation. - - Fix: when the unavailable-tool error is caught, every tool call in `stepToolCalls` that doesn't already have a result should receive a synthetic tool-result explaining the failure (e.g. "This step was aborted because tool X is unavailable."). The existing per-tool synthetic result only covers the offending tool; the rest of the batch becomes orphaned. - - Beyond the unavailable-tool case more generally: any path that yields tool-call events without a matching tool-result leaves the history in an un-roundtrippable state. Consider adding a `failed` or `aborted` state to tool results so the model can distinguish "the tool ran and returned this output" from "the tool never ran because something went wrong upstream." +- **Fix the todo system.** The current task list tool and its UI have bugs or limitations that need addressing. + + |