fix(muse): preserve compact errors and retry after busy runs#28455

🟠 High server/adapter.ts:2151

A wake that requests approval or user input can deadlock compaction: its request is buffered instead of being shown, while compactWhenIdle waits for that wake's run to complete. Because the continuation that replays the buffer is queued behind compaction, the user cannot answer and compaction cannot retry; let interactive wake requests reach handleRequestEvent while preserving the wake's other output.

Fixed. While a compaction turn is active, every approval or question is shown as a runless request instead of being buffered. That includes ones the held wake buffered before compaction began: only request notifications leave the buffer, and the wake's other output stays queued for its continuation. Runless settlements now bypass turn routing, so a request shown during a compaction that is then stopped still resolves. The new approval cases and "settles a request shown during compaction after the compaction is stopped" in adapter.test.ts deadlock on the previous head and pass now.

External image Minor · Stability & Availability · Quick win

Do not re-read wake after failHost can clear it.

failHost sets wake = undefined. Line 2196 passes failHost to Effect.catch. If a buffered request notification fails to decode, failHost runs mid-loop. The next non-request event reaches wake.events.push on Line 2197 with wake undefined. That throws a TypeError defect from start instead of the typed failure.

Collect the events to keep in a local array. Push them back once, and only if wake still exists.

✅ Confirmed as addressed by @shivamhwp

Fixed in 2c764e3cfe: the loop keeps a local reference to the buffered wake, so a failHost that clears wake mid-loop no longer turns the next push into a TypeError.

@shivamhwp Thanks for the fix. The local buffered reference avoids reading wake after failHost clears it.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

🟠 High server/adapter.ts:1407

After compaction is stopped, an approval/updated for a runless request is buffered or dropped, leaving the UI and decideApproval with stale approval options and currentRequirementId. Only settlements for pending runless requests bypass turn routing here, and publishRequest no longer recognizes the update as runless once active is undefined; route updates for existing runless approvals through that path and preserve their runless association when republishing.

Fixed in d87e7be927. Any request notification for an existing runless request now bypasses turn routing, and publishRequest keeps a request runless when its previous entry was. The "keeps a request shown during compaction live after the compaction is stopped" case sends approval/updated after Stop and asserts approval/decide uses the new requirement id. It hangs on the previous head.

🟠 High server/adapter.ts:1449

An automatic compaction from the held wake can finish the manual turn before its requested compaction is admitted, so the requested compaction is never sent. This exception accepts any compaction item while active.compact is true; require compactAdmitted before routing the item to the manual turn.

Fixed in d87e7be927. The compact turn now tracks sending / waiting / admitted. While it is waiting after a run_active rejection, compaction items are not routed to it, so a held wake's own compaction stays in the wake buffer. I gated on "not waiting" rather than "admitted" because Muse may emit the requested compaction item before the command ack. The approval cases now emit an automatic compaction item while compaction waits. They fail on the previous head.

This fixes the waiting phase, but the original race remains during sending: a held wake’s completed compaction can arrive before the run_active rejection and still finish the manual turn before the requested compaction is admitted.

External image Major · Data Integrity & Integration · Heavy lift

Preserve each wake during compaction.

A background task can start a second wake after the first run settles but before its held continuation is dispatched. If compaction is still active, handleNotification drops the second wake’s non-compaction items. Its output can be missing from the transcript.

If the first wake is consumed while the second still runs, the pending-work probe can also return false when no observed children remain. Idle release can then close the host.

Track each held wake with its own buffer and continuation. Add a test that checks the second wake’s output.

Not changing this in this PR. Holding only one wake predates it: on main, any run that starts while a wake is already held is dropped (else if (!active && !wake)), with or without compaction, and on main a run that starts during compaction is dropped too. This PR now keeps the first one during compaction. The part that could hang Muse is fixed in 4239e37: approvals and questions from a live run that no turn owns (such as wake-2) are now shown and can be answered, including after Stop. Keeping a separate buffer and continuation for each wake changes how all wakes work, not just compaction, so it belongs in its own change.

@shivamhwp Agreed. The single-wake limit predates this PR, and the new routing handles requests from unowned live runs. I’ll withdraw the finding as a regression in this PR.

The potential missing-output and idle-release risks remain separate follow-up work. Would you like me to open a GitHub issue for them?

Review thread resolved.

_{You are interacting with an AI system.}

🟠 High server/adapter.ts:1434

When wake already holds wake-1, a second wake such as wake-2 is dropped while compaction is active, so its response never reaches the conversation and no continuation is offered for it. This branch only retains a new run when !wake; preserve subsequent wake runs and their events until compaction completes.

Not changing this in this PR. Holding only one wake predates it: on main, any run that starts while a wake is already held is dropped (else if (!active && !wake)), with or without compaction, and on main a run that starts during compaction is dropped too. This PR now keeps the first one during compaction. The part that could hang Muse is fixed in 4239e37: approvals and questions from a live run that no turn owns (such as wake-2) are now shown and can be answered, including after Stop. Keeping a separate buffer and continuation for each wake changes how all wakes work, not just compaction, so it belongs in its own change.

Understood, thanks for the context.