Skip to content

Fix silent message loss: globally unique Nats-Msg-Id (2.2.1 hotfix) - #39

Merged
majkelx merged 1 commit into
masterfrom
fix/dedup-id-collision
Aug 7, 2026
Merged

majkelx merged 1 commit into
masterfrom
fix/dedup-id-collision

Conversation

@majkelx

@majkelx majkelx commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Fixes #38.

2.2.0 uses meta.id as the JetStream Nats-Msg-Id — but gen_id is process-locally sequential, so ids collide across processes and restarts on any shared stream, and JetStream silently drops the later publishes as duplicates (verified: PubAck.duplicate=True for a different subject of the same stream).

Fix: dedup header becomes <instance>:<meta.id> with a random per-process token generated once per Messenger. Ack-timeout retries still reuse the identical header (the #18 protection stays intact); cross-process/restart collisions are impossible. Message envelope unchanged.

Tests: new test_publish_no_cross_process_dedup_collision (forced same meta.id from a simulated foreign process — both messages must be stored) + updated header assertions. Full suite: 311 passed, 8 skipped, 1 xfailed.

Deployment note: all services running 2.2.0 (ofp, tcs, halina) should upgrade promptly — the bug is silent data loss on shared streams.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HfMGwatJe81U9aekr51R7f

@majkelx
majkelx merged commit 5c9241f into master Aug 7, 2026
2 checks passed
@majkelx
majkelx deleted the fix/dedup-id-collision branch August 7, 2026 14:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2.2.0: Nats-Msg-Id from process-local meta.id silently drops messages (cross-process dedup collision)

1 participant