You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Stop does not work on OpenAI Compatible API Provider #404
Stopping an in-progress question or task does not abort the underlying HTTP request to the provider. The provider continues processing / generating tokens, invisible to the user.
This bug was already reported on Roo code: RooCodeInc/Roo-Code#10779. It still is present in Zoo code 3.56.0.
Context (who is affected and when)
OpenAI API users. I use llama.cpp on a iGPU as local solution (a propos, dedicated support for llama.cpp would be welcome at some point) which now continues its lengthy process even though I hit the stop button in Zoo.
Reproduction steps
Configure OpenAI API compatible provider, e.g. local llama.cpp setup
Give Zoo a prompt
Hit the stop button.
Expected result
Underlying HTTP request is immediatly aborted
Actual result
Underlying HTTP request continues until the end, consuming precious resources, while of no benefit to the user.
Variations tried (optional)
No response
App Version
3.56.0
API Provider (optional)
OpenAI Compatible
Model Used (optional)
N/A
Zoo Code Task Links (optional)
No response
Relevant logs or errors (optional)
If I quit VS Code, the (stopped, but continuing) request is immediately terminated, as is shown in the log of llama.cpp:
1332.16.787.326 W srv stop: cancel task, id_task = 153
1332.20.921.482 I slot release: id 0 | task 153 | stop processing: n_tokens = 4096, truncated = 0
1332.20.921.542 I srv update_slots: all slots are idle
I've identified the root cause: the and do not create an or pass an abort signal to the underlying OpenAI SDK / AI SDK requests. When the user hits Stop, the Task-level breaks out of the stream loop, but the HTTP request continues running server-side until it finishes naturally.
In contrast, and both correctly create an and pass to their API calls.
Fix plan:
Add to both and
Create the controller in / , pass to the SDK calls
Evidence recorded by the lane auditing this objective's declarations. Posted as evidence with a question, not as a claim that either declaration is wrong.
What closed it. Pull #1309, merged 2026-11-04T04:38:05Z — two seconds before this issue's close stamp 2026-11-04T04:38:07Z — titled "feat(api): abort-signal wiring for lm-studio and qwen-code (round 2)". The closing references this issue reports are three: #1309 MERGED 2026-11-04T04:38:05Z (head 3933b64), #1291 OPEN and unmerged (head a4a629a), and #1311 OPEN and unmerged (head 0a14d67).
Why that needs a maintainer rather than a housekeeping pass.#404 is a decomposed objective — stop/abort working against OpenAI-compatible-style providers — and the family that landed first marked the shared objective completed. #1309 delivers the lm-studio and qwen-code half. The two pulls that declare Closes #404 carry the other halves: #1291 the openai-native wiring, #1311 the openai and openai-compatible wiring. Both are still open and unmerged, so when they merge their Closes lines will close nothing, because the objective is already closed, and nothing in this repository records those two families as still owed.
What we are not claiming. Neither declaration is being called false. Each points at a real issue describing the objective its pull serves; both were simply overtaken by another family's landing. For that reason no body on #1291 or #1311 was amended and nothing was posted on either pull. The issue has not been reopened, and was not: reopening is not among the writes this campaign's token has demonstrated it can perform.
Timeline shape, for the record. 247 items in this issue's timeline. The first 40 read back as 1 LabeledEvent, 1 IssueComment, 9 CrossReferencedEvent, 25 ReferencedEvent and 4 SubIssueAddedEvent. Nine of those items are cross-references; the pull-sourced ones in that window include #429, #1, #434, #620 and #625, every one of them closed without a merge commit. Five months of inbound references are how a decomposed objective ends up in this state.
The question, bounded. For the remaining families, would you rather reopen #404, or have the campaign file one issue per undelivered family — openai-native, and openai/openai-compatible — and leave this objective closed? Both answers are workable; the campaign will file whichever you pick rather than choose for you.
Activity
proyectoauraorg commentedon Jun 1, 2026
Claiming.
I've identified the root cause: the and do not create an or pass an abort signal to the underlying OpenAI SDK / AI SDK requests. When the user hits Stop, the Task-level breaks out of the stream loop, but the HTTP request continues running server-side until it finishes naturally.
In contrast, and both correctly create an and pass to their API calls.
Fix plan:
Will follow up with a PR shortly.
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streamText() for OpenAI Compatible prov…
fix(api): pass abortSignal to streaming API calls for all providers (Z…
fix(tests): remove unused createMockStream helpers from abort signal …
feat(api): pass abortSignal to streaming API calls for all providers (Z…
178 remaining items
🐛 fix(test): update opencode-go spec assertions for upstream provider…
🐛 fix(e2e): update glm-5-turbo max_tokens assertion (Zoo-Code-Org#404)
🐛 fix(providers): clean up abort listeners to prevent MaxListenersExc…
🐛 fix(e2e): fix zai fetch interceptor request capture and timing (Zoo…
🐛 fix(e2e): update glm-5-turbo max_tokens assertion (Zoo-Code-Org#404)
🐛 fix(providers): clean up abort listeners to prevent MaxListenersExc…
🐛 fix(e2e): fix zai fetch interceptor request capture and timing (Zoo…
🐛 test(mcp): fix McpHub Windows command wrapping test ordering (Zoo-C…
feat(api): abort signal support for openrouter (completePrompt + crea…
feat(api): abort signal support for opencode-go
feat(api): shared abort-signal cancellation-scope helpers (Zoo-Code-O…
EuphoricPenguin commentedon Oct 5, 2026
#1651 was supposed to fix this issue, but unless it isn't on the prerelease version of Zoo Code yet, this is still an issue.
fix(api): forward discovery cancellation into the Kimi catalog fetch
easonLiangWorldedtech commentedon Nov 11, 2026
Evidence recorded by the lane auditing this objective's declarations. Posted as evidence with a question, not as a claim that either declaration is wrong.
What closed it. Pull #1309, merged 2026-11-04T04:38:05Z — two seconds before this issue's close stamp 2026-11-04T04:38:07Z — titled "feat(api): abort-signal wiring for lm-studio and qwen-code (round 2)". The closing references this issue reports are three: #1309 MERGED 2026-11-04T04:38:05Z (head 3933b64), #1291 OPEN and unmerged (head a4a629a), and #1311 OPEN and unmerged (head 0a14d67).
Why that needs a maintainer rather than a housekeeping pass. #404 is a decomposed objective — stop/abort working against OpenAI-compatible-style providers — and the family that landed first marked the shared objective completed. #1309 delivers the lm-studio and qwen-code half. The two pulls that declare
Closes #404carry the other halves: #1291 the openai-native wiring, #1311 the openai and openai-compatible wiring. Both are still open and unmerged, so when they merge theirCloseslines will close nothing, because the objective is already closed, and nothing in this repository records those two families as still owed.What we are not claiming. Neither declaration is being called false. Each points at a real issue describing the objective its pull serves; both were simply overtaken by another family's landing. For that reason no body on #1291 or #1311 was amended and nothing was posted on either pull. The issue has not been reopened, and was not: reopening is not among the writes this campaign's token has demonstrated it can perform.
Timeline shape, for the record. 247 items in this issue's timeline. The first 40 read back as 1 LabeledEvent, 1 IssueComment, 9 CrossReferencedEvent, 25 ReferencedEvent and 4 SubIssueAddedEvent. Nine of those items are cross-references; the pull-sourced ones in that window include #429, #1, #434, #620 and #625, every one of them closed without a merge commit. Five months of inbound references are how a decomposed objective ends up in this state.
The question, bounded. For the remaining families, would you rather reopen #404, or have the campaign file one issue per undelivered family — openai-native, and openai/openai-compatible — and leave this objective closed? Both answers are workable; the campaign will file whichever you pick rather than choose for you.