lsm / neokai / 28134258755

82%

push

github

docs: clarify null-failureReason pending delivery invariant (#2176)

A `pending` delivery row with a null `failureReason` is, by contract,
still owned by its original in-process dispatch path. The activation
flush (`collectPersistedPendingDeliveries`) intentionally skips these to
avoid duplicate dispatch; the three in-process owners are the in-memory
pending queue, an in-flight dispatch, and a pending rate-limit digest
(for which this filter is the *only* guard against a duplicate).

The counterpart to that skip is crash recovery: rows left pending+null
by an interruption are re-queued by `requeuePersistedPendingDeliveries`
on the next rehydrate, which re-queues ALL pending rows (null or not),
so the skip never strands a valid delivery permanently.

- Expand the filter comment and the `ExternalEventDeliveryState` doc to
  state this invariant explicitly (the original comment omitted the
  in-memory queue owner and the crash-recovery net).
- Add focused unit coverage pinning both halves: the activation flush
  leaves a pending+null row untouched (verified to fail when the filter
  is removed), and requeue recovers a pending+null row after a simulated
  crash so it is delivered on the next activation.

11362 of 16393 branches covered (69.31%)

Branch coverage included in aggregate %.

95212 of 113555 relevant lines covered (83.85%)

267.18 hits per line