fix(infinity-daemon): don't flush deferred subscription events while an async tool call is in flight#59
Open
shadaj wants to merge 1 commit into
Open
Conversation
…an async tool call is in flight A subscription event (or thread report) arriving while a non-sleep async tool call (e.g. a RAP `edit_file`) was awaiting its result could interrupt that call: `handle_content` injects a synthetic "Tool call interrupted by user" result and sends RAP cancellations, even though the tool actually completed — its real result arrives later and is dropped as stale. **Root cause:** `thread_worker` already defers deferrable synthetic events (subscription events / thread reports / parent messages) into `pending_non_interrupt_items` while waiting for an async tool result, but the unconditional `pending_non_interrupt_items.drain(..)` when building `all_inputs` flushed them anyway whenever *any* non-deferrable item was present — e.g. a stale/duplicate tool result. In the reported session the duplicate `tooluse_LVEs…` result caused the deferred `tooluse_6zyy…` subscription event to be flushed, interrupting the in-flight `tooluse_y9Yx…` `edit_file` call. Changes in `crates/infinity-daemon/src/session/thread_worker.rs`: * Add `pending_non_sleep_tool_call()` helper returning the id of the trailing unanswered non-sleep tool call; reuse it for the existing `waiting_for_non_sleep_tool` check * Guard the pending-items drain: deferred events are only flushed when it is safe — no non-sleep tool call is pending, or the batch settles it first (contains the call's actual tool result, or a user text input, which deliberately interrupts). Otherwise only non-deferrable pending items are processed and deferrable events stay queued for a later iteration * Add regression test `stale_result_does_not_flush_deferred_events_during_async_tool_wait` reproducing the log scenario (subscription event + stale tool result while an async tool is in flight); verified it fails without the fix and passes with it `./check.bash` passes. Note: the lambda path (`infinity-agent-lambda/src/event_handler.rs`) has no deferral mechanism at all and can theoretically hit the same interruption; fixing it would require re-enqueueing/delaying SQS messages and is left as a follow-up. Co-authored-by: Infinity 🤖 <infinity@hydro.run> PR: #59
Deploying infinity with
|
| Latest commit: |
56ce647
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://0e9e9466.infinity-dc7.pages.dev |
| Branch Preview URL: | https://sandbox-3b52f581-f974-4530-b.infinity-dc7.pages.dev |
shadaj
marked this pull request as ready for review
July 8, 2026 20:38
shadaj
force-pushed
the
sandbox-3b52f581-f974-4530-b68b-70c1ddee8dd9
branch
from
July 8, 2026 22:34
a72e47d to
56ce647
Compare
There was a problem hiding this comment.
Pull request overview
This PR fixes a race in infinity-daemon’s thread worker where deferrable synthetic events (subscription events / thread reports / parent messages) could be flushed and processed while a non-sleep async tool call is still in flight, causing handle_content to inject a synthetic “interrupted” tool result and cancel an operation that actually completes later.
Changes:
- Add
pending_non_sleep_tool_call()to detect a trailing in-flight non-sleep tool call and reuse it for the existing “waiting for async tool” check. - Prevent draining (flushing) deferrable synthetic events from
pending_non_interrupt_itemsunless it’s safe (no in-flight tool call, or the current batch settles/interrupts it first). - Add a regression test reproducing the stale tool-result + deferred subscription-event scenario.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+1435
to
+1446
| // Yield so the worker can process the batch. | ||
| for _ in 0..4 { | ||
| tokio::task::yield_now().await; | ||
| } | ||
|
|
||
| // 3. Neither the stale result nor the (still deferred) | ||
| // subscription event should have triggered a completion, | ||
| // and the pending tool call must not have been interrupted. | ||
| assert!( | ||
| ctrl.try_next_request().is_none(), | ||
| "deferred subscription event must not be flushed by a stale tool result" | ||
| ); |
MingweiSamuel
approved these changes
Jul 17, 2026
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
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.
A subscription event (or thread report) arriving while a non-sleep async
tool call (e.g. a RAP
edit_file) was awaiting its result could interruptthat call:
handle_contentinjects a synthetic "Tool call interrupted byuser" result and sends RAP cancellations, even though the tool actually
completed — its real result arrives later and is dropped as stale.
Root cause:
thread_workeralready defers deferrable synthetic events(subscription events / thread reports / parent messages) into
pending_non_interrupt_itemswhile waiting for an async tool result, butthe unconditional
pending_non_interrupt_items.drain(..)when buildingall_inputsflushed them anyway whenever any non-deferrable item waspresent — e.g. a stale/duplicate tool result. In the reported session the
duplicate
tooluse_LVEs…result caused the deferredtooluse_6zyy…subscription event to be flushed, interrupting the in-flight
tooluse_y9Yx…edit_filecall.Changes in
crates/infinity-daemon/src/session/thread_worker.rs:pending_non_sleep_tool_call()helper returning the id of thetrailing unanswered non-sleep tool call; reuse it for the existing
waiting_for_non_sleep_toolcheckis safe — no non-sleep tool call is pending, or the batch settles it
first (contains the call's actual tool result, or a user text input,
which deliberately interrupts). Otherwise only non-deferrable pending
items are processed and deferrable events stay queued for a later
iteration
stale_result_does_not_flush_deferred_events_during_async_tool_waitreproducing the log scenario (subscription event + stale tool result
while an async tool is in flight); verified it fails without the fix
and passes with it
./check.bashpasses. Note: the lambda path(
infinity-agent-lambda/src/event_handler.rs) has no deferral mechanismat all and can theoretically hit the same interruption; fixing it would
require re-enqueueing/delaying SQS messages and is left as a follow-up.