fix(invite): hold the loading state until the stored token resolves - #6488
Conversation
Two gaps left by #6486. The query was gated on isTokenResolved but the loading state was not. With enabled: false React Query still reports success when the key already holds data, so a cached null-token entry made isPending false and rendered the accept UI for one frame before the effect applied the stored token. Reachable only on a client-side remount after a tokenless fetch already succeeded. An empty ?token= also stopped falling back to storage: searchParams.get returns '' which is not null, so token became '' where the pre-#6486 truthiness check had read sessionStorage. Normalize to null at the source.
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryLow Risk Overview Loading UI now stays on the skeleton until the stored token is read from Empty Reviewed by Cursor Bugbot for commit 8493aeb. Configure here. |
Greptile SummaryThis PR fixes invitation initialization by treating an empty query token as absent and keeping signed-in users in the loading state until session-storage token resolution completes.
Confidence Score: 5/5The PR appears safe to merge, with no actionable correctness, security, or maintainability issue identified in the changed behavior. The storage-resolution effect always resolves the token sentinel, the query remains disabled until that resolution, and empty query values now correctly follow the existing storage fallback path.
|
| Filename | Overview |
|---|---|
| apps/sim/app/invite/[id]/invite.tsx | Correctly aligns loading UI with token resolution and restores stored-token fallback for empty query parameters; no actionable regression identified. |
Reviews (1): Last reviewed commit: "fix(invite): hold the loading state unti..." | Re-trigger Greptile
Summary
Closes two gaps left by #6486, both in
apps/sim/app/invite/[id]/invite.tsx.Loading state didn't follow the query gate. #6486 gated the invitation query on
isTokenResolvedbut leftisLoadingreading onlyinvitationQuery.isPending. Withenabled: falseReact Query still reportssuccesswhen the key already holds data, so a cached null-token entry makesisPendingfalse — the accept UI renders for one frame before the effect applies the stored token. Now!isTokenResolved || invitationQuery.isPending.Empty
?token=stopped falling back to storage.searchParams.get('token')returns'', which is notnull, sotokenbecame''where the pre-#6486 truthiness check (if (tokenFromQuery)) had readsessionStorage. Normalized with|| nullat the source, restoring the original behavior.Found by Cursor Bugbot on #6487 (the release PR), plus a re-check of my own change while verifying its claim.
Type of Change
Testing
bun run type-check,bun run lint:check(23/23),vitest run app/invite(6 tests) all pass.Behavior is unchanged on every reachable path except the two defects:
?token=isPendingtrue, empty cache)!isTokenResolved) — same?token=xyzisTokenResolvedtrue →isPendingisLoadingfalse?token=(empty)''No permanent-skeleton risk: the effect always runs on mount and
sessionStorage.getItemreturnsstring | null, neverundefined, soisTokenResolvedalways becomes true.Not browser-tested — the changed paths are a loading frame and an empty-param edge case.
Checklist