fix(server): stop replaying old agent alerts on restart#13340

🟡 Medium relay/AgentAwarenessRelay.ts:280

A terminal turn that settles after restart without a materialized latestTurn is filtered out, so its post-restart Done alert is never published. Because latestUserMessageAt is old while session.updatedAt is new, the workStartedAt > startedAt && sessionUpdatedAt > startedAt check returns false in both the startup snapshot and first publish; accept the post-restart session update for this no-checkpoint case.

I checked the session lifecycle. restoreCompaction can set an existing session back to ready with a new updatedAt (ProviderCommandReactor.ts:440-459) without a new user turn. Accepting sessionUpdatedAt > startedAt alone would let that old thread emit a fresh Done alert after restart, which is the reported bug. If this process has already published an active state, the map allows its completion. For a terminal state seen first, we require evidence that the work itself began or finished after startup.

🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift

Do not treat a user message as evidence of completed work.

A thread.turn.start request can have a pending turn without a shell latestTurn. The projector materializes latestTurn only when it receives a thread.session-set event with status: "running" and an activeTurnId. Meanwhile, thread.message-sent updates latestUserMessageAt, and a ready session projects as completed.

terminalWorkSinceStart then treats the message timestamp plus a post-start session update as terminal work. The five-second confirmation only delays this projection. If the running-session update is delayed or fails, the relay can publish a false “Done” before the provider turn starts.

Require running-session or turn-completion evidence before allowing an initial completed publish for a thread without a latestTurn.

✅ Confirmed as addressed by @juliusmarminge

Fixed in 5e56aa5. An initial terminal publish now requires a latestTurn.completedAt after startup. A newly sent message plus a ready session no longer qualifies, and the regression test covers that case in both startup selection and direct publish.

@juliusmarminge, the regression tests confirm the reported case. Startup selection excludes the thread with a recent user message and a ready session. Direct publish also sends no alert for that thread. I inspected the tests but did not run them.

✅ Review thread resolved.

You are interacting with an AI system.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Include post-start failures without a materialized turn.

Startup reconciliation can set an orphaned session to error after restart. If the thread has no projected latestTurn, the projection has no running turn to update, so session.updatedAt is the only post-start terminal timestamp. An older latestUserMessageAt then leaves terminalWorkSinceStart false, and the failed state is excluded.

Treat a post-start failure transition as terminal work.

I checked this path. Startup reconciliation marking an old orphaned session as failed is recovery of pre-restart work, not a new agent failure. Sending a push for it would recreate the old-thread alert burst. If this process first publishes the thread as active, its later failure still publishes through the existing state map. An initial terminal state without observed work stays quiet by design.

@juliusmarminge, you’re right. A post-start session.updatedAt can reflect reconciliation of pre-restart work. Treating it alone as a new failure could restore the old alerts. The existing published-state check allows a later failure to publish if this process first published the thread as active. I withdraw the suggestion.

✅ Review thread resolved.

You are interacting with an AI system.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Include terminal no-latestTurn sessions in startup catch-up.

projectThreadAwareness treats a ready or idle session without latestTurn as completed. The current predicate reads only latestTurn.completedAt, so it excludes this valid terminal state from startup catch-up and skips its initial “Done” publish.

Use an authoritative session completion signal for this path. Do not use latestUserMessageAt.

The shell has no authoritative completion signal in this case. session.updatedAt is also advanced by recovery code such as restoreCompaction in ProviderCommandReactor.ts, which can set an old session to ready after restart. Treating that as a fresh completion would recreate the reported alert flood. If this process observed the thread as active, its terminal update is allowed through the published-state map. I documented the remaining no-turn, no-observed-active case as a limitation in the PR body.

@juliusmarminge, the repository check confirms your point. restoreCompaction sets the session to ready and advances session.updatedAt without establishing that a turn just completed. Using that timestamp for startup catch-up could replay an old “Done” alert. The relay also permits a terminal publish when this process has already published an active state for the thread.

I withdraw the finding.

✅ Review thread resolved.

You are interacting with an AI system.