Skip to content

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
mainfrom
sandbox-3b52f581-f974-4530-b68b-70c1ddee8dd9
Open

fix(infinity-daemon): don't flush deferred subscription events while an async tool call is in flight#59
shadaj wants to merge 1 commit into
mainfrom
sandbox-3b52f581-f974-4530-b68b-70c1ddee8dd9

Conversation

@shadaj

@shadaj shadaj commented Jul 8, 2026

Copy link
Copy Markdown
Member

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.

…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
@cloudflare-workers-and-pages

cloudflare-workers-and-pages Bot commented Jul 8, 2026

Copy link
Copy Markdown

Deploying infinity with  Cloudflare Pages  Cloudflare Pages

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

View logs

@shadaj
shadaj marked this pull request as ready for review July 8, 2026 20:38
@shadaj
shadaj force-pushed the sandbox-3b52f581-f974-4530-b68b-70c1ddee8dd9 branch from a72e47d to 56ce647 Compare July 8, 2026 22:34
@MingweiSamuel
MingweiSamuel requested a review from Copilot July 16, 2026 22:09

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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_items unless 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"
);
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants