fix(reactions): recompute mine per-client on socket updates (un-react didn't revert)#748
Merged
Merged
Conversation
emitReactionChange computes `mine` for the user who triggered the add/remove and broadcasts that ONE view to the whole pod room. Every other client then adopts a wrong `mine` — which flips the add/remove toggle (clicking your own reaction POSTs/re-adds instead of DELETE/removing it: "un-react didn't revert") and mis-highlights chips. 2026-07-24: reported after a second account reacted. Fix: the socket handler recomputes `mine` for THIS client from each reaction's `users` list (already on the wire), falling back to the broadcast value only when `users` is absent (older server / Mongo fallback). Extracted as the pure `recomputeReactionMine` so it's unit-tested. Backend un-react already works (DELETE removes correctly); this was purely the client trusting a broadcast `mine` that wasn't its own. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMeWzgFxsfBcjoLVLewEES
useV2PodDetail reads currentUser to recompute reaction `mine` per-client; useAuth throws without an AuthProvider, so this renderHook-based suite needs the stub. Only affected suite; other hook consumers already provide/mocked it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DMeWzgFxsfBcjoLVLewEES
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
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.
Bug (2026-07-24)
Clicking your own reaction a second time didn't remove it, and chips could highlight as "yours" when they weren't.
emitReactionChangecomputesminefrom the reactor's id and broadcasts that singlereactionsarray to the wholepod_<id>room:So after account B reacts, account A's client receives B's
mineview and adopts it. The bubble usesmineto decide POST-vs-DELETE on click — so A clicking its own reaction can POST (re-add, idempotent → "nothing happened") instead of DELETE. Verified the backend un-react is correct (DELETE removes the caller's reaction, count 2→1); this was purely the client trusting a foreignmine.Fix
The socket handler recomputes
minefor the current client from each reaction'suserslist (already sent over the wire byreactionAttributionService), falling back to the broadcast value only whenusersis absent. Extracted as the purerecomputeReactionMinehelper.Test
recomputeReactionMine.test.ts— recomputes true/false from the user list, and falls back to the wire value whenusersoruserIdis missing.This is the last of the reaction-bug layers (❤️ validation #744, membership 403 #746, and now the
minebroadcast).🤖 Generated with Claude Code
https://claude.ai/code/session_01DMeWzgFxsfBcjoLVLewEES