A device froze permanently in a two-phone test. Debugger stacks showed an
ABBA deadlock: the main actor was in bleQueue.sync (delivery-ack send →
broadcastPacket → readLinkState) while bleQueue was in main.sync
(captureBluetoothStatus reading backgroundTimeRemaining). The load that
lined the two edges up came from a courier-drop amplification storm:
drop dedup was in-memory only while the outbox driving 120s re-deposits
is persisted, so every relaunch republished the same undelivered DM as a
fresh 24h relay drop and every gateway relaunch re-fetched the whole
backlog — ~20 copies of one DM delivered in 40ms, each triggering
decrypt + delivery + ack + handshake work.
Fixes, in rank order:
- Edge B (P0): captureBluetoothStatus no longer main.syncs from bleQueue;
backgroundTimeRemaining is sampled on main and cached behind a lock.
Invariant documented: bleQueue must NEVER sync-dispatch to main.
- Edge A (P0, defense in depth): sendDeliveryAck / sendReadReceipt /
sendPrivateMessage / sendNoisePayload / triggerHandshake hop to
messageQueue like sendMessage, so no main-actor call path reaches
readLinkState's bleQueue.sync.
- Drop dedup (P1): publishedDropKeys and seenDropEventIDs persist across
relaunches (new BridgeDropDedupStore, entries expire with the 24h
NIP-40 drop window; wiped on panic) — one drop per message ID per 24h
regardless of relaunch count.
- Receiver dedup (P1): openCourierEnvelope dedups on the inner private
message ID before delivery, so a duplicate copy costs one decrypt and
never re-delivers, re-acks, or re-triggers a handshake.
- Handshake gating (P2): queued acks initiate a Noise handshake only for
reachable peers; mail from absent/rotated identities no longer turns
each copy into a mesh-wide handshake flood (the ack stays queued and
flushes when a session eventually establishes).
- Outbox (P3): re-enqueueing a queued message ID carries over its
depositedCourierKeys so resends stop re-burning the same courier slots.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
