fix(server): subagent runs no longer delay replies

[Deepusleepy]

During large subagent runs, background progress events could pile up ahead of assistant events. The assistant had replied, but T3 Code was still processing old progress updates, so the reply looked missing.

Replies and other realtime events now move ahead of queued background telemetry. Replaceable progress updates are collapsed to their newest state instead of replaying every intermediate tick.

How it works:

• ProviderRuntimeIngestion routes task lifecycle events, task-owned tool progress, and thread usage updates through a background lane. Conversation events stay realtime.
• PriorityCoalescingWorker checks the realtime queue before each background item and keeps one queued value per task or telemetry key.
• Task lifecycle merges preserve started/progress/updated/completed order, and partial task.updated patches keep fields reported by earlier patches.
• One failed event no longer terminates the worker and strands everything behind it. A session exit also prevents overtaken task telemetry from restoring stale background activity.

Focused tests cover realtime priority, task coalescing, partial updates, processor failures, and session-exit ordering.

---

Note

Medium Risk
Changes core orchestration ingestion ordering and merging for all provider runtime events; incorrect coalescing could drop or mis-order task state, though scope is limited to telemetry lanes with extensive tests.

Overview
Fixes replies appearing stuck behind large subagent runs by replacing the single FIFO drain worker in ProviderRuntimeIngestion with makePriorityCoalescingWorker: conversation and other non-telemetry events stay on a realtime lane, while task lifecycle, task-scoped tool.progress, and thread.token-usage.updated go to background lanes keyed per thread/task and collapse to the latest tick instead of replaying every intermediate update.

Adds mergeBackgroundIngestion so coalesced task.progress / task.updated batches keep partial fields (usage max-merge, activity vs usage-only ticks, lifecycle order including reactivation after task.completed).

Guards: task liveness is not recorded when session.status === "stopped" (stale telemetry after session.exited); processor failures no longer kill the worker loop.

New packages/shared/PriorityCoalescingWorker is exported and covered by unit tests; ingestion behavior is covered by expanded activity/merge tests and an integration test for post-exit liveness.

^{Reviewed by Cursor Bugbot for commit 053539b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix subagent runs delaying replies by prioritizing realtime events over background ingestion

• Replaces makeDrainableWorker with a new makePriorityCoalescingWorker in ProviderRuntimeIngestion.ts that processes realtime events before background ones, so subagent task telemetry no longer blocks reply delivery.
• Background task lifecycle events (e.g. task.progress, task.updated) are coalesced per task key, merging usage metrics via max-merge and preserving the latest activity state, reducing redundant processing.
• After a provider session exits, subsequent task lifecycle telemetry no longer updates background liveness for that thread.
• The new PriorityCoalescingWorker.ts module exposes enqueueRealtime, enqueueBackground(key, value), and drain, and survives processor failures by swallowing non-interrupt errors.
• Behavioral Change: task.progress events that include phases are now treated as having activity state, replacing the previous per-task progress activity row rather than overlaying it.

^{Macroscope summarized 053539b.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ddaf630e-91fc-4062-8f32-d99ca9ceba52

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a new PriorityCoalescingWorker infrastructure component and fundamentally changes how runtime events are processed, prioritized, and coalesced. This is significant new capability that warrants human review, not a straightforward bug fix. Additionally, there is an unresolved Medium severity finding about phase ticks potentially wiping progress text.

^{You can customize Macroscope's approvability policy. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 053539b. Configure here.}

[cursor]

Phase ticks can wipe progress text

Medium Severity

hasTaskProgressActivityState now treats any payload with phases as a full activity snapshot. A later tick that only refreshes workflow phases (often alongside typedUsage, without repeating summary, lastToolName, or error) replaces the stable task-progress row and coalesced payload, so the last visible progress text can disappear.

Additional Locations (1)

• apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts#L176-L183

 

^{Reviewed by Cursor Bugbot for commit 053539b. Configure here.}

[juliusmarminge]

Thanks for the PR. We're not taking changes to the orchestration and provider layers right now: that part of the server is being rewritten for V2, and merging into the current code would either conflict with or be thrown away by that work.

Closing for now. If this is still an issue once V2 lands, please reopen (or open a fresh PR against the new code) and we'll take a proper look.