getResolvedMarmotGroupEventIds is what a reindex sweep subtracts from a room's
stored group events to decide what to replay, so its answer decides what work
the sweep does -- and both ways of being wrong are silent.
Report an event as resolved when it is not, and the replay skips the one event
that needed it: the message stays missing from the feed with nothing left to
trigger another attempt. Report it as unresolved when it is resolved, and every
sweep re-decrypts it forever. The whole distinction rests on `messageType NOT IN
(:unresolvedTypes)`, where those types are the two placeholder lines that stand
in for a message still to come rather than reporting one.
Covered: an event with a real line is resolved; an undecryptable outer layer and
a pending commit each leave their event unresolved, which is right because those
are precisely what a replay exists to retry. Then the subtraction itself, since
that is how the caller uses it -- three events, one settled, one holding a
placeholder, one with no line at all, and the sweep left with exactly the last
two.
Covered because the query says so and nothing else would: `marmotGroupEventId IS
NOT NULL` keeps out lines that are not about a group event -- a NIP-17 direct
message, a locally written line -- which would otherwise carry nulls into a set
the sweep subtracts with. And the room scoping, since a sweep runs per room and
another room's resolutions must not shorten its work.
Covered last, and it is the transition the sweep exists to cause: a placeholder
upserted in place into a real line resolves its event, visible through this same
query.
Two smaller ones alongside: the single-row lookups order newest first, which is
what makes them "the line for this event" rather than whichever row sqlite
reached first, and the per-sender count is scoped to its room.
Verified by mutation: defeating the messageType exclusion so placeholders count
as resolved fails five of these, including the subtraction test. The mutation
was reverted; no production source is touched by this commit.
8 tests. composeApp jvmTest is 282 tests, 0 failures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
baecb76253