Acknowledged messages are re-delivered, and a replayed authorisation looks like a fresh one #140

New issue

Open

opened 2026-08-28 00:59:54 +00:00 by jlxq0 · 0 comments

jlxq0 commented

2026-08-28 00:59:54 +00:00

Owner

Four of Julian's messages were re-delivered to Clark with replayed="true"
after mark_read returned success on those same event ids. Two of the four
were authorisations.

event A   an instruction to proceed
event B   a one-word authorisation
event C   an authorisation naming a credential
event D   a question                              (replayed twice)

(Bodies and event ids withheld: this repository is public and these are the
principal's private messages. They are in the operator's own record.)

The mount's own instructions say the acknowledgement "is the only record that it
reached you, and anything unacknowledged is re-delivered the next time this
session starts". Every one of these was acknowledged and the tool reported
success.

Why this is not tidiness

A replayed authorisation is indistinguishable from a fresh one. The tag
carries replayed="true" and nothing else marks it, so a session that had
already acted on event B or event C and then compacted or resumed from a
summary would act on it again.

Tonight that would have been a second attempt to delete something already
deleted, which is harmless. The shape is not: "go" releases a hold, and a
release that arrives twice cannot be told from a release and a re-release by a
reader who no longer remembers the first.

Every director resumed from a summary today, so "already acted on it" is a state
none of them can reliably check about themselves.

Two explanations and the reporter could not separate them

The re-delivery queue was populated before the receipt landed, so each
message was already committed to one replay.
The receipt does not suppress delivery at all.

Exactly one replay each fits the first. event D replaying twice
against two mark_read calls does not fit it cleanly, and that is the
observation worth starting from rather than the count of four.

What would separate them

A mark_read whose success is observed at the server rather than reported by
the client: read the receipt back from the room state after the call, and
re-deliver only what has no receipt. If receipts are landing and re-delivery
ignores them, the two explanations come apart immediately.

Not a client fix

replayed="true" already exists and is already delivered, so a session can
tell a replay from a push. What it cannot tell is whether it acted on that
event before, which is a property of the session rather than of the message.

Suppressing an acknowledged message at the source is the fix. Asking every
reader to keep a ledger of event ids it has acted on is the same work done seven
times, badly, in sessions that lose it to a summary.

Four of Julian's messages were re-delivered to Clark with `replayed="true"` **after `mark_read` returned success on those same event ids**. Two of the four were authorisations. event A an instruction to proceed event B a one-word authorisation event C an authorisation naming a credential event D a question (replayed twice) (Bodies and event ids withheld: this repository is public and these are the principal's private messages. They are in the operator's own record.) The mount's own instructions say the acknowledgement "is the only record that it reached you, and anything unacknowledged is re-delivered the next time this session starts". Every one of these was acknowledged and the tool reported success. ## Why this is not tidiness **A replayed authorisation is indistinguishable from a fresh one.** The tag carries `replayed="true"` and nothing else marks it, so a session that had already acted on event B or event C and then compacted or resumed from a summary would act on it again. Tonight that would have been a second attempt to delete something already deleted, which is harmless. **The shape is not**: `"go"` releases a hold, and a release that arrives twice cannot be told from a release and a re-release by a reader who no longer remembers the first. Every director resumed from a summary today, so "already acted on it" is a state none of them can reliably check about themselves. ## Two explanations and the reporter could not separate them - The re-delivery queue was populated **before** the receipt landed, so each message was already committed to one replay. - The receipt **does not suppress** delivery at all. **Exactly one replay each fits the first.** event D replaying **twice** against two `mark_read` calls does not fit it cleanly, and that is the observation worth starting from rather than the count of four. ## What would separate them A `mark_read` whose success is observed at the server rather than reported by the client: read the receipt back from the room state after the call, and re-deliver only what has no receipt. If receipts are landing and re-delivery ignores them, the two explanations come apart immediately. ## Not a client fix `replayed="true"` already exists and is already delivered, so a session *can* tell a replay from a push. What it cannot tell is whether **it** acted on that event before, which is a property of the session rather than of the message. **Suppressing an acknowledged message at the source is the fix.** Asking every reader to keep a ledger of event ids it has acted on is the same work done seven times, badly, in sessions that lose it to a summary.