fix(bridge): dedupe KYC webhook deliveries — CAS transitions + lock-first#434
Merged
Merged
Conversation
…irst First live KYC test on TEST fired the "approved" push twice: two distinct events (customer.created racing customer.updated) both read the pre-update status, passed the previousStatus guard, and notified. Bridge delivery retries would duplicate pushes the same way in prod. Two-layer fix: 1. Atomic status transition (new AccountsRepository transitionBridgeKycStatus): findOneAndUpdate guarded on bridgeKycStatus != next, reporting whether THIS call changed it. The kyc handler now gates notifications AND side effects (virtual account auto-creation) on winning the transition — racing deliveries collapse to exactly one notification and one side-effect pass. All five status branches unified on the same flow. 2. Lock-first: the event_id idempotency lock was taken at the END of the handler — pure bookkeeping that prevented nothing. It now runs before any reads or writes. Same late-lock bug fixed in the external-account route (it persisted the account before checking); transfer already locked first, deposit is deliberately structured (audit outside, credit inside its lock) and left alone. 8 kyc handler tests (2 new: race-loser skips side effects; duplicate event_id short-circuits before touching the account); 87 webhook-server tests green. Refs the ENG-461/flags-on TEST validation session.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
First live KYC test on TEST produced a duplicated "identity verification approved" push:
customer.createdracedcustomer.updated, both read the pre-update status, both notified. Bridge's delivery retries would do the same in prod.transitionBridgeKycStatus): status update guarded on!= next, reporting whether this call won. Notifications and side effects (virtual-account auto-create) only fire for the winner — races and retries collapse to exactly one of each. The five copy-pasted status branches are unified on one flow.event_ididempotency lock ran at the end of the kyc handler (bookkeeping only); it now runs before any reads/writes. Same fix applied to the external-account route, which persisted before checking.transferalready correct;depositdeliberately structured and untouched.Test plan
Found during flags-on TEST validation (sandbox auto-approval surfaced the race on the very first event).
🤖 Generated with Claude Code