fix(web): a deleted message never counts as unread#565
Open
gbasin wants to merge 1 commit into
Open
Conversation
The server stopped counting deleted messages toward a channel's unread counter, but the timeline's "N new" pill still counted a deleted message that kept its tombstone to host replies. The pill could say "1 new" while the sidebar said nothing, and the new thing was the words "Message deleted". Deletion takes the content away, so there is nothing left to have missed. Any replies still under the tombstone announce themselves through their own broadcast events. Renderability and unread are now separate questions, because they have different answers: a deleted message with replies still paints a row, so it is still the newest thing a reader can scroll to, but it is never something to catch up on. Conflating the two is what stranded a channel unread forever.
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.
Last of the #562 follow-ups. Closes the client/server disagreement about what counts as unread.
The divergence
#562 made the server exclude deleted messages from
latest_event_id. The client'sunreadCountonly excluded messages that render nothing (deleted && replyCount === 0).So a deleted message that still has replies counted as unread on the client but not the server: the pill says
1 new, the sidebar says nothing, and the "new" thing is the words "Message deleted".The fix
countsAsUnread— deletion always removes the unread content. Replies under the tombstone announce themselves through their own broadcast events.Renderability and unread are now separate questions, because they have different answers:
isRenderableMessagecountsAsUnreadA deleted-with-replies message still paints a row, so it's still the newest thing a reader can scroll to — but it's never something to catch up on. Conflating those two is what stranded
#test-channelunread forever.countsAsUnreadstrictly subsumesisRenderableMessage's deleted case, sounreadCountneeds only the one predicate and the #562 guarantee still holds.firstUnreadIduses it too: if only a tombstone lies past the watermark it returnsnulland takes the existing bottom-landing path; if real unread follows, the divider skips the tombstone and targets that. No change to mark-read or the read cursor — reading is still only marked at the bottom.Verification
The new test fails without the fix — the pill renders
1 newfor a deleted-with-replies message.Local:
pnpm lint·typecheck(7/7) · web 776 · shared 452 · e2e 119/119, including theread-positionandhistory-read-cursorspecs that guard against swallowing unread.🤖 Generated with Claude Code