Nothing else drains BroadcastNostrEventRequest, so a row this DAO fails to hand
back is an event that never reaches any relay -- and the failure is silent,
because a queue returning nothing is indistinguishable from an empty one.
That already happened. The observer's predicate carried a `createdAt > :now`
bound whose `now` was evaluated once, when the Flow was built. Instants persist
at second resolution, so it hid every broadcast enqueued during the observer's
own start second -- the entire profile-creation burst -- plus everything a
previous session had left pending. There is a test here for exactly that shape:
a row enqueued before the observer existed has to come back.
The stale sweep, which is the other half of not losing events. A request is
flipped to "processing" before a publish is attempted, and a timeout or a
dropped socket leaves it there; nothing observes "processing" or "failed", so
those rows are dead weight until the sweep requeues them. Covered: both stale
statuses flip to "pending" and are counted; a row already pending is not
touched, so the returned count is not inflated by work that was never stale.
Covered separately, because it is the reason the sweep is bounded at all: a row
newer than the cutoff is left alone. A publish running right now holds its row
in "processing", and requeueing that would hand the same event to a second
publish while the first is still in flight. The bound is `<=`, so a row stamped
exactly on the cutoff second is swept -- asserted, since that is the boundary
the second resolution of these timestamps makes common rather than rare.
Also covered: the queue drains oldest first; a "processing" row is not handed
out as pending work; and getFirstBroadcastNostrEventRequestByNostrEventId
returns the oldest of an event's per-relay rows rather than the only one, since
an event is queued once per target relay.
One test is deliberately kept despite not being able to fail, and says so in its
own comment. `requests sharing a timestamp drain in insertion order` pins the
observable order of a same-second burst, which is what callers depend on -- but
deleting the `, id ASC` tiebreak leaves it passing, because `id` is an
autoGenerate primary key and therefore the rowid, so sqlite's unspecified
ordering already coincides with it under this plan. That coincidence is the
argument for keeping the explicit tiebreak rather than against it: it is not
contractual, and an index or a different plan can change it. Recording the limit
in the test seemed better than implying a guard that is not there.
Verified by mutation: reversing the drain order fails the oldest-first test.
Removing only the tiebreak fails nothing, which is how the limitation above was
found rather than assumed. Both mutations were reverted; no production source is
touched by this commit.
9 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
d355b68355