You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Membership and user rows drift between MongoDB (source of truth) and PostgreSQL (chat mirror). Surfaced 2026-07-24: Commonly HQ had 66 Mongo pod.members but only 1 in PG pod_members, so 65/66 members 403'd on reactions (fixed for reactions via a Mongo fallback in #746 + a one-off backfill; this issue tracks the root).
Two drifts:
pod_members: ensureUserInCommunityPod (HQ auto-join) and likely other join paths (invite redeem, etc.) write Mongo pod.members but never mirror to PG pod_members. Any PG-gated access/read check then mis-treats real members as non-members.
users: registration creates the Mongo user but doesn't sync to PG users — 5 HQ members aren't in PG users at all (the message path lazily backfills on first message; fix(register): mirror the default workspace pod into Postgres #743 fixed this for the auto-workspace pod, not users generally). PG-user-dependent features (message author render) show these as "Unknown" until they send a message.
Why it matters
Anything gating on PG (callerHasPodAccess's human path did, before #746; possibly other reaction/message/read checks) silently mistreats members. The failures are invisible when the caller swallows errors.
Options
Mirror on write: ensureUserInCommunityPod + join paths call PGPod.addMember (and syncUserToPostgreSQL) like createPod does. Correct data, but every join path must remember.
Reconciliation sweep: periodic job backfilling PG pod_members/users from Mongo. Catches drift regardless of path.
Recommend Mongo-fallback for access checks (done for reactions) + a reconciliation sweep, and audit other PG-gated reads for the same 403-real-members risk.
Acceptance
A member in Mongo pod.members is never 403'd by a PG-gated check.
New community/invite joins land in PG pod_members.
Registration users reachable in PG (or all PG reads tolerate their absence).
Problem
Membership and user rows drift between MongoDB (source of truth) and PostgreSQL (chat mirror). Surfaced 2026-07-24: Commonly HQ had 66 Mongo
pod.membersbut only 1 in PGpod_members, so 65/66 members 403'd on reactions (fixed for reactions via a Mongo fallback in #746 + a one-off backfill; this issue tracks the root).Two drifts:
pod_members:ensureUserInCommunityPod(HQ auto-join) and likely other join paths (invite redeem, etc.) write Mongopod.membersbut never mirror to PGpod_members. Any PG-gated access/read check then mis-treats real members as non-members.users: registration creates the Mongo user but doesn't sync to PGusers— 5 HQ members aren't in PGusersat all (the message path lazily backfills on first message; fix(register): mirror the default workspace pod into Postgres #743 fixed this for the auto-workspace pod, not users generally). PG-user-dependent features (message author render) show these as "Unknown" until they send a message.Why it matters
Anything gating on PG (
callerHasPodAccess's human path did, before #746; possibly other reaction/message/read checks) silently mistreats members. The failures are invisible when the caller swallows errors.Options
ensureUserInCommunityPod+ join paths callPGPod.addMember(andsyncUserToPostgreSQL) likecreatePoddoes. Correct data, but every join path must remember.pod_members/usersfrom Mongo. Catches drift regardless of path.Recommend Mongo-fallback for access checks (done for reactions) + a reconciliation sweep, and audit other PG-gated reads for the same 403-real-members risk.
Acceptance
pod.membersis never 403'd by a PG-gated check.pod_members.Context: reaction 403 incident, #746 / #743.