fix(reactions): human pod-access falls back to Mongo membership (PG pod_members drift)#746
Merged
Merged
Conversation
…rift) callerHasPodAccess gated human reactions ONLY on PG pod_members, but that table is a lazily-synced mirror of Mongo pod.members — community auto-join (ensureUserInCommunityPod) and other join paths write Mongo only. Result: members whose PG row never synced got 403, silently (frontend swallows it), so reaction counts appeared stuck at 1. 2026-07-24: Commonly HQ had 66 Mongo members but 1 in PG pod_members → 65/66 could not react. Fix: after the PG fast-path misses, fall back to Mongo pod.members (the source of truth) — the same fallback the agent path already had. (Also backfilled HQ's PG pod_members out-of-band for the immediate fix; this makes it robust for all pods + future joins + users not yet in PG.) Test: two new cases — human in Mongo-but-not-PG is allowed; human in neither → 403. 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
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.
Bug (2026-07-24, launch — the real "count stuck at 1")
Reaction counts appeared frozen at 1 for everyone but the reactor. Root cause:
callerHasPodAccessgates human reactions solely on PGpod_members:But PG
pod_membersis a lazily-synced mirror of Mongopod.members. Community auto-join (ensureUserInCommunityPod) and other join paths write Mongo only. So members whose PG row never synced got 403 — and the frontend swallows reaction errors, so it just looked like the count wouldn't move.Measured on Commonly HQ: 66 Mongo members, 1 in PG
pod_members→ 65 of 66 members silently 403'd on every reaction. The only member who could react was the single one present in PG, so counts never exceeded 1.Fix
Give the human path the Mongo fallback the agent path already has: after the PG fast-path misses, check Mongo
pod.members(the source of truth).pod_membersout-of-band for the immediate fix (verified live: a previously-403'd member reacted →👍:2).Test
Two new cases in
reactionController.test.js: human in Mongo-but-not-PG → allowed; human in neither → 403. Suite green (15 tests).Related drift (follow-up worth filing)
ensureUserInCommunityPod(and other join paths) should mirror membership to PGpod_members; 5 HQ members aren't even in the PGuserstable (registration doesn't sync users to PG — same family as #743). The Mongo fallback covers reaction access regardless, but other PG-gated reads may want the same treatment.🤖 Generated with Claude Code
https://claude.ai/code/session_01DMeWzgFxsfBcjoLVLewEES