Repository navigation
fix: run no tool once the run is stopped during its start handlers - #495
Merged
Merged
Conversation
The loop checked for a stop before the tool_execution_start handlers and not after, so a stop that came while a handler ran still let the tool execute: a write landed after the stop. It now checks again and reports the call as stopped. Implemented by Sol (gpt-6.1-sol), who found it reading loop.ts; reproduced and checked by Claude.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part 7 of the move to Effect became fixing the places in the engine's loop that do not hear a stop (debated with GPT-6 Astra and GPT-6.1 Sol, and measured; the owner approved fixing them directly rather than moving
loop.tsto Effect). This is the tool that started after a stop. Implemented by Sol (gpt-6.1-sol), who found it readingloop.ts; reproduced and checked by Claude.Defect
runCall(packages/core/src/loop.ts) checked for a stop before awaiting thetool_execution_starthandlers and not after. A stop that came while a handler ran still let the tool execute. Reproduced ondev: a handler held during the stop, then released; the run ended aborted, and thewritecall's file was written after the stop.Change
One line: after the start handlers return, a stopped run reports the call as stopped (
stoppedCall), as it does when the stop came before. Its intent and result are recorded as before.Checks
packages/core/tests/conformance.test.ts: a start handler held during the stop; the run ends aborted, the file is not written, and the call's result is an error. It fails ondev(the file exists) and passes with the change; checked by Sol and again by Claude.bun run check(Sol, Windows): root 264 passed; engine 332 passed, 3 skipped; types and lint clean. The budget failed on shell memory on this machine (123.6 MB, limit 115 MB); CI decides.