Skip to content

[BUG] Stop does not work on OpenAI Compatible API Provider #404

Closed
1 of 4 issues completed
Closed

Description

@Fuzzillogic

Problem (one or two sentences)

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

  1. Configure OpenAI API compatible provider, e.g. local llama.cpp setup
  2. Give Zoo a prompt
  3. 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

Activity

  1. proyectoauraorg commented on Jun 1, 2026

    @proyectoauraorg
    Contributor

    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:

    1. Add to both and
    2. Create the controller in / , pass to the SDK calls
    3. Check in the stream iteration loop
    4. Add abort support
    5. Regression tests

    Will follow up with a PR shortly.

  2. 178 remaining items

  3. EuphoricPenguin commented on Oct 5, 2026

    @EuphoricPenguin

    #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.

  4. easonLiangWorldedtech commented on Nov 11, 2026

    @easonLiangWorldedtech
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions