read_marker: Tolerate backfilled events in private read markers - #566
Open
ruka-hamanasu wants to merge 2 commits into
Open
read_marker: Tolerate backfilled events in private read markers#566ruka-hamanasu wants to merge 2 commits into
ruka-hamanasu wants to merge 2 commits into
Conversation
added 2 commits
August 28, 2026 19:05
Posting m.read.private at a backfilled event failed the entire /read_markers request with M_INVALID_PARAM. In a room joined over federation where the latest message predates the join, every message a client can target is backfilled, so no read marker, public receipt, or notification reset could ever be posted there; the room stayed unread for such clients forever. A backfilled position orders below every live event, so storing it can never advance the marker. Skip the write like a non-advancing receipt instead of erroring: the request succeeds, the accompanying public receipt and fully-read marker are still stored, and the notification-count reset on advance still runs.
9 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Posting m.read.private at a backfilled event failed the entire /read_markers request with M_INVALID_PARAM. In a room joined over federation where the latest message predates the join, every message a client can target is backfilled, so no read marker, public receipt, or notification reset could ever be posted there; the room stayed unread for such clients forever.
A backfilled position orders below every live event, so storing it can never advance the marker. Skip the write like a non-advancing receipt instead of erroring: the request succeeds, the accompanying public receipt and fully-read marker are still stored, and the notification-count reset on advance still runs.
The client/server spec says nothing about backfilled events, so the error appears to be from a desire to indicate to clients that they requested something Tuwunel couldn't entirely fulfill rather than indicating a request that was truly invalid from a protocol standpoint. In the case I tested, it was a request to set the read marker to the same event it was already on, so a no-op in terms of moving the read marker, but an important one because otherwise the client will never show the room as read. Worst case, it should be harmless to accept and skip, because it's not like clients do anything useful with the 400 error.
Fairly niche case, but also an extremely simple fix.
Checklist
cargo fmtand satisfies clippy andrustc lints; any allowed lint is justified by an obvious reason or a
comment.
are noted in the description above.
src/core/config/mod.rsdoccomments and the regenerated
tuwunel-example.tomlis committed.docs/.and my conduct is in line with the Contributor's Covenant and
Tuwunel's Code of Conduct.