Their username is .FiftyNine595. Please log a ticket to investigate this.
Why can’t I see my firms transaction history even though im logged in on an account linked to my mc account which owns the firm?
Activity
Ttesks created the issue
RRÃan Errity moved to team PAR (PAR-85)
T
tesks
Root-caused and fixed on develop (economy-explorer 87e573c).
Why it was device-dependent (desktop works, mobile doesn't, same account): the Auth.js session JWT was storing the full Keycloak access_tokenandrefresh_token — two large JWTs — that the explorer never actually uses (it reads the economy DB directly, never calls Keycloak APIs). That bloated the NextAuth session cookie past the ~4 KB browser limit, so Auth.js split it into chunks. Mobile browsers / Safari (ITP + stricter cookie caps) drop or truncate those chunks, so auth() couldn't decode the session → getViewer fell back to anonymous → the user saw none of their own (linked) data. Desktop browsers tolerate the larger/chunked cookie, so it worked there. Hence "same account, different device, different result."
It's not the durable link: explorer_identity is keyed on keycloak_sub (PK; there's only a non-unique index on the player UUID), so findIdentityBySub is fully deterministic per Keycloak account — once the row exists, every session for that sub resolves the same player regardless of device. The failure was the session itself not surviving on mobile.
Fix: drop the access/refresh tokens (and the unused refresh dance) from the session JWT — keep only sub + the minecraft_uuid/minecraft_name claim. The cookie is now tiny and survives mobile; session lifetime is governed by Auth.js's own JWT maxAge. Existing users on a broken/truncated cookie just need to sign in again once.
Typecheck + 65 unit tests green.
Note on .FiftyNine595: that's a Floodgate (Bedrock) dot-prefixed name. This fix restores the session reliably; if that specific player still can't see their firm after re-login, the remaining angle is a Java-vs-Floodgate UUID mismatch between the firm's proprietor UUID and the linked UUID — worth a quick check once they re-test, but separate from this session-cookie bug.
Related: the still-open INFRA item to add UNIQUE(player_uuid_bin) on explorer_identity (stops two Keycloak subs claiming the same player) is a separate integrity hardening — the viewer comment that claimed this constraint already exists has been corrected.
PParadauxIO set status to Done
PParadauxIO linked a commit: Commit 87e573c — Stop bloating the session cookie so login is reliable on mobile (PAR-85)
Workspace permission required to comment
Comments and reactions require workspace permission. Ask a workspace owner or admin for access. You can sign in to vote.
Root-caused and fixed on
develop(economy-explorer87e573c).Why it was device-dependent (desktop works, mobile doesn't, same account): the Auth.js session JWT was storing the full Keycloak
access_tokenandrefresh_token— two large JWTs — that the explorer never actually uses (it reads the economy DB directly, never calls Keycloak APIs). That bloated the NextAuth session cookie past the ~4 KB browser limit, so Auth.js split it into chunks. Mobile browsers / Safari (ITP + stricter cookie caps) drop or truncate those chunks, soauth()couldn't decode the session →getViewerfell back to anonymous → the user saw none of their own (linked) data. Desktop browsers tolerate the larger/chunked cookie, so it worked there. Hence "same account, different device, different result."It's not the durable link:
explorer_identityis keyed onkeycloak_sub(PK; there's only a non-unique index on the player UUID), sofindIdentityBySubis fully deterministic per Keycloak account — once the row exists, every session for that sub resolves the same player regardless of device. The failure was the session itself not surviving on mobile.Fix: drop the access/refresh tokens (and the unused refresh dance) from the session JWT — keep only
sub+ theminecraft_uuid/minecraft_nameclaim. The cookie is now tiny and survives mobile; session lifetime is governed by Auth.js's own JWT maxAge. Existing users on a broken/truncated cookie just need to sign in again once.Typecheck + 65 unit tests green.
Note on
.FiftyNine595: that's a Floodgate (Bedrock) dot-prefixed name. This fix restores the session reliably; if that specific player still can't see their firm after re-login, the remaining angle is a Java-vs-Floodgate UUID mismatch between the firm's proprietor UUID and the linked UUID — worth a quick check once they re-test, but separate from this session-cookie bug.Related: the still-open INFRA item to add
UNIQUE(player_uuid_bin)onexplorer_identity(stops two Keycloak subs claiming the same player) is a separate integrity hardening — the viewer comment that claimed this constraint already exists has been corrected.