Two of these queries carry a comment describing a bug that already shipped, and
neither bug was the kind anything catches by running: a wrong WHERE clause is
still a valid query returning a plausible list. Both corrected predicates are
now pinned, so the next edit has to argue with a failing test rather than with
a comment.
getMarmotGroupEvents. The predicate used to read `expiresAt < :now`, which kept
exactly the expired events and dropped every live one -- for the whole
group-chat sync path the set handed to negentropy was the complement of the
relay's. Covered with four rows at once: no expiry at all (always served), an
expiry in the future (still served), an expiry in the past (gone), and an
expiry landing exactly on `now`, which the strict `>` excludes. Also covered:
the inclusive since/until bounds using events stamped on each bound, room
membership filtering across two rooms, and newest-first ordering with a limit
keeping the newest window.
getMarmotGroupNostrEventsByChatRoomId. Ascending order, because a replay has to
apply commits in the order they were sent and this is the one query in the DAO
that deliberately orders that way. The test that matters most here is that an
event which never reached the MarmotGroupEvent table is still returned -- that
is the whole reason the query reads NostrEvent instead of joining the index,
since an event whose indexing failed part way is precisely what a replay exists
to pick up, and a join would skip exactly those rows. Asserted from both sides:
the un-indexed event comes back from the replay query and is genuinely absent
from getMarmotGroupEvents.
The same query's LIKE over-match is pinned deliberately rather than asserted
away. The DAO's comment calls it a prefilter and puts the burden on callers to
confirm the event's own `h` tag, so a room id sitting in an `e` tag is expected
to come back. Recording it in both directions means anyone tightening the query
knows a caller may rely on the loose behaviour, and anyone loosening a caller's
check knows why it was there.
Also covered: getNostrEventByPublicKeyAndKind returning the newest row, which
is what makes it correct for replaceable events rather than a coin flip; and
the difference between the two write paths, where `insert` with IGNORE keeps
the stored event -- correct when re-receiving an immutable event from a second
relay -- while `upsert` overwrites it.
Last, the paged reads are pinned as treating `since` exclusively, which is what
makes them safe to call in a loop with the previous page's last timestamp as
the cursor. That sits one query away from the inclusive bound in
getMarmotGroupEvents on purpose: the two conventions are genuinely different,
and a reader who assumes either holds throughout gets a skipped row or a loop
that never advances.
The expiry test was checked by mutation rather than assumed: restoring
`expiresAt < :now` fails it alone, with "an event expiring in the future is
still live". The mutation was reverted; no production source is touched by this
commit.
11 tests. composeApp jvmTest is 239 tests, 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
20d2547a34