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?
Comments
tesks · Jun 6, 2026, 12:14 PM
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.
Activity
ParadauxIO linked a pull request — PR #9 open — Release economy-explorer → main (perf fixes + 1.1.0 RBAC/RUM)Jun 7, 2026, 7:36 PM
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.