What was wrong

A Pax user (Trey) sent two quick Slack messages in one thread: "Yes, try to schedule for early next week", then "run it by me before sending". Each was its own Slack event and its own agent run. Run 2 started before run 1 had persisted anything (chat rows were only written when a run finished), so it saw none of run 1's work, re-derived the task with a different calendar call, and its draft-email overwrote run 1's Gmail draft (same draftId). Cedar showed Trey the first run's 3 slots, then saved and previewed a different 4-slot draft.

Evidence: chat_messages for thread slack:T0789EW2ZM3:D0BPM9PPL0P:1790269797.716889. Two user rows with Slack ts 1790269827 and 1790269841 (14s apart) and two draft-email tool results on draftId r163057067623954677, with different bodies. Turn 1 rows were written at 17:11:15 UTC, after turn 2 had already started.

What changed

• The user's message is persisted on arrival, with its Slack send time and author (metadata.authorUserId).
• Each run polls the DB (1.5s) for a newer message from the same author and aborts via an AbortSignal passed to the agent. A final check() runs before anything is persisted, so a run that finishes as a newer message lands still loses. The aborted run persists and posts nothing and deletes its "thinking" placeholder.
• The newer run reloads history, so it sees the earlier unanswered message, and gets a prompt note: treat them as one request, and update any existing draft/task rather than duplicate it.
• persistCompletedChatMessages now merges metadata on user rows so the arrival-time author is not wiped on completion. Other rows keep replace semantics.
• Only the same author's messages cancel a run or are merged into the note, so teammates in a shared channel thread cannot cancel each other or run under each other's identity.

Polling reads the DB rather than process memory because the two events can land on different API instances.

Known limits

• The abort lands on the next poll tick and cannot interrupt a tool call already executing, so the older run can still finish one in-flight write. The prompt note narrows the duplicate-draft race but does not close it.
• If the newer run dies after persisting, neither message gets a reply; the next message picks up both.
• Voice notes are not covered (they get a row only after transcription).
• The prompt note has not been run against the live model; unit tests cover the mechanism, not the model's response to the note.

How to test

Unit: pnpm --filter @zero/server exec vitest run src/mastra/utils src/mastra/routeHandlers/slack. Manual: in a Slack thread with Cedar, send "draft a reply to X" and, within a few seconds, "show me before sending". Expect one reply covering both, and only one Gmail draft.

Verify in prod (Axiom cedar-prod, CloudWatch /aws/ecs/aws-prod-api/api-service)

['cedar-prod']
| where message == '[slack-turn-supersession] Superseded , aborting run'
| project _time, user_id, thread_id, user_message_id

Each row is a run that was cancelled. The matching thread should show exactly one assistant reply after it:

['cedar-prod']
| where message == '[persistCompletedChatMessages] Saved' and thread_id startswith 'slack:'
| where thread_id == '<thread_id from above>'

Failure signal: [slack-turn-supersession] Supersession check failed warns (DB poll errors), or a superseded thread with two assistant replies.

Notes

autofix:local stops on one unrelated frontend test (apps/mail/tests/modules/chat-store/chatHistoryList.test.ts, a date-bucket test). Lint, deps:check, server typecheck and the server vitest suites for this area pass.

🤖 Generated with Claude Code