[Bug] Completed /refine leaves the spinner running after a daemon resync

[rain-lee1999]

Summary

In daemon-backed interactive mode, Refining continual harness state... can remain visible after refinement succeeds. Resuming the same session clears it.

An extension automatically submitted /refine in the observed session. This uses the same session-command path as a typed /refine; it was not a manual user action. The saved session contains both the successful refinement and its session_slash_command_result.

Version

Checked upstream main at cd1f215cffd09223316c54dddae5e1b654718c31 (package version 0.9.6). The relevant loader and resync methods are unchanged from the locally reproduced version. Local reproduction used macOS and Node 24.19.0.

Reproduction and cause

Two isolated, provider-free replays reproduce the failure mechanism:

1. Send a refinement command's message_start to the interactive UI. The refine loader starts.
2. Complete refinement, then deliver an authoritative idle resync snapshot containing the command and its successful result, instead of delivering the result's live message_start.
3. The loader remains visible. Delivering the live result event normally clears it; resetting the session view also clears it.

Separately, replaying the observed outcome/notice/completion message sizes through production daemon delivery methods and a real private-framed Unix socket caused the output buffer to reach 68,687 bytes with a default 65,536-byte high-water mark. The receiver was reading normally. Both command-result events were skipped and a resync was queued. No model calls, forced backpressure flag, or fake socket were used. Historical socket packets were not captured, so this is a causal reproduction rather than a packet trace of the original occurrence.

The transport intentionally substitutes snapshots for events under backpressure. However, InteractiveMode stops the refine loader only on the live command-result event. renderResyncedSession() does not reconcile refinement completion from the snapshot, and syncWorkingLoader() keeps remounting the stale loader.

Expected behavior

A resync containing the matching completed refinement should clear its loader. An older result must not clear a newer pending refinement, and a snapshot with an unfinished refinement must keep showing it.

A local fix now reconciles the loader from ordered snapshot command/result records and retains newer pending refinements. Regression coverage includes completed and failed commands, missing starts, repeated commands, and command-ID mismatches. Removing snapshot reconciliation makes five regression cases fail. Would you be open to a PR for this? I have not opened an unsolicited upstream PR. No private conversation or harness content is included in this report.

[awhite0030]

Investigated this report and produced a candidate fix, validated on a fork of this repository.

Root cause, fix and validation from the working notes:

Root cause: A completed /refine command leaves the spinner visible after a daemon resync because the InteractiveMode loader state was only cleared upon receiving the live session_slash_command_result event, ignoring the state within snapshot messages loaded during resync.

Fix: Added a routine inside renderResyncedSession() that scans the snapshot's messages for /refine session_slash_command and session_slash_command_result custom messages. It starts the spinner if a refinement is pending and discards it if the refinement has completed or if there are none.

Validation: Wrote a regression test packages/coding-agent/test/suite/regressions/2873-refine-spinner-resync.test.ts to assert that the refineLoader clears when a completed refinement is restored, and correctly persists when an uncompleted refinement is restored. Ran the regression tests locally using Vitest. Ran npm run check and verified zero compilation/linting errors.
Upstream discussion: #2873

Diff: awhite0030/prime-agent@main...fix/2873-refine-spinner-resync-9787782507837704432
Full pull request: awhite0030#96

The change passes npm run check and the focused regression tests against current main. If a fix for this is still wanted, I can open a pull request.