fix(awareness-service): dedupe deliveries by content hash so envelope updates re-deliver#989
Conversation
… updates re-deliver (#984)
…llable-backfill-notnull column add
|
Warning Review limit reached
More reviews will be available in 46 minutes and 36 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Description of change
Fixes the delivery dedup collision in
awareness-servicethat silently dropped every MetaEnvelope update after the first ingest.Deliverywas uniquely keyed on(subscriptionId, packetId), and sincePacketis upserted on the MetaEnvelope id, every re-ingest of an updated envelope reused the samepacketId.IngestService.ingestinserts with.orIgnore(), so the second delivery hit the unique key and was silently discarded — a subscriber received each envelope exactly once, ever.The MetaEnvelope id (
packetId) is intentionally not part of the dedup decision anymore; content is. The fix adds acontentHashcolumn toDeliveryand changes the unique key to(subscriptionId, packetId, contentHash):.orIgnore()still dedupes. ✅contentHash=sha256(stableStringify(payload.data)), wherestableStringifysorts object keys recursively so key ordering does not affect the hash.Includes a TypeORM-generated migration (
1780404367748-AddDeliveryContentHash). The raw generatedADD ... NOT NULLwould fail on a populateddeliveriestable, so it adds the column nullable → backfills legacy rows with a constant → setsNOT NULL, then swaps the unique constraint.Issue Number
#984
Type of change
How the change has been tested
npm run build(tsc) inservices/awareness-service/apipasses.Initschema applied and a pre-existing delivery row:migration:runsucceeds, the legacy row is backfilled (contentHash = ''), the column ends upNOT NULL, and the unique constraint becomes(subscriptionId, packetId, contentHash).migration:revertcleanly drops the column and restoresuq_delivery_subscription_packet..orIgnore(); changed re-ingest produces a newcontentHashand queues a new delivery, so the delivery count increments.Change checklist