Atomic claim before lead creation — prevent orphan pooled leads

Shipped: July 3, 2026 at 3:37 AM UTC
Author: Kamo
Commit: 7dae7d3

social.lead.new can be processed concurrently (old + new SecurityService pod both hold a core-NATS subscription during a RollingUpdate → one publish delivered to both). The prior check-then-act idempotency test raced, letting the loser create a pooled lead with no SocialRemoteUserLead mapping (un-joinable social conversation). Now the unique (connectionId, remoteUserId) index is claimed via saveAndFlush BEFORE any lead is created; the loser skips, and a post-claim failure releases the claim for clean retry. Caught by Meta E2E.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free Forever View Pricing