fix: isolate assistant projection identities per thread

[binbandit]

Summary

• key projected thread messages by (thread_id, message_id) so reused assistant IDs no longer overwrite another thread's projection row
• make new runtime/checkpoint assistant identities thread-scoped while preserving legacy persisted IDs during upgrade and resume flows
• add regression coverage for cross-thread item ID reuse, legacy upgrade resume behavior, and checkpoint fallback identity resolution

Why

• issue Assistant message projections collide across threads when message IDs are reused #871 is a reliability bug in the core thread projection path: reusing a provider-backed assistant identity across threads can overwrite the first thread's assistant message
• the original persistence conflict key used message_id alone, and runtime-generated assistant IDs were not consistently thread-scoped
• upgraded installs also needed compatibility so existing persisted assistant/checkpoint IDs keep resolving instead of duplicating assistant messages after resume

Changes

• add migration 014_ProjectionThreadMessagesThreadScopedKey to rebuild projection_thread_messages with a composite primary key on (thread_id, message_id)
• update ProjectionThreadMessages upserts and attachment carry-forward logic to scope conflicts and lookups by thread
• add assistantMessageIdentity helpers and use them in ProviderRuntimeIngestion and CheckpointReactor to mint thread-scoped IDs for new data while reusing legacy IDs when they already exist in projections
• update websocket/runtime expectations and add focused regression tests for persistence isolation and legacy compatibility

Validation

• bun fmt
• bun lint
• bun typecheck
• bun run test src/orchestration/assistantMessageIdentity.test.ts src/persistence/Layers/ProjectionThreadMessages.test.ts src/orchestration/Layers/ProviderRuntimeIngestion.test.ts src/wsServer.test.ts

Note

Isolate assistant message IDs per thread in projection and runtime ingestion

• Assistant message IDs are now namespaced by threadId (e.g. assistant:{threadId}:item:{itemId}) instead of being derived globally from item/turn/event IDs, preventing cross-thread collisions.
• New helpers resolveRuntimeAssistantMessageId and resolveCheckpointAssistantMessageId handle ID resolution, reusing legacy persisted IDs when a thread resumes from an existing checkpoint.
• ProjectionThreadMessages upserts are now keyed on (thread_id, message_id) instead of message_id alone, scoping attachment preservation to the correct thread.
• Migration 014 re-creates the projection_thread_messages table with a composite primary key (thread_id, message_id).
• Risk: message ID values emitted via thread.message-sent and related events will change for new messages; existing persisted IDs are detected and reused to preserve continuity for resumed threads.

^{Macroscope summarized f17c579.}

[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

Run ID: 8358fcea-b40c-4d97-91d8-8368a5a887d4

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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 and usage tips.}

[binbandit]

@juliusmarminge if we can, can we please prioritise this one?