fix(invite): hold the loading state until the stored token resolves

[waleedlatif1]

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 isTokenResolved but left isLoading reading only invitationQuery.isPending. With enabled: false React Query still reports success when the key already holds data, so a cached null-token entry makes isPending false — 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 not null, so token became '' where the pre-#6486 truthiness check (if (tokenFromQuery)) had read sessionStorage. Normalized with || null at 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

• Bug fix

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:

Path	Before	After
Cold load, no ?token=	skeleton (isPending true, empty cache)	skeleton (!isTokenResolved) — same
?token=xyz	isTokenResolved true → isPending	unchanged
Signed out	isLoading false	unchanged
Remount w/ cached null-token entry	stale accept UI for one frame	skeleton — fixed
?token= (empty)	queried with ''	falls back to storage — restored

No permanent-skeleton risk: the effect always runs on mount and sessionStorage.getItem returns string | null, never undefined, so isTokenResolved always becomes true.

Not browser-tested — the changed paths are a loading frame and an empty-param edge case.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Aug 10, 2026 6:33am

[cursor]

PR Summary

Low Risk
Small UI/state fix in the invite flow with no auth or API contract changes.

Overview
Fixes two invite-page regressions after gating the invitation query on isTokenResolved.

Loading UI now stays on the skeleton until the stored token is read from sessionStorage, not only while React Query is pending. That avoids a one-frame flash of the accept UI when a cached null-token query entry makes isPending false before the effect applies the stored token.

Empty ?token= is normalized to null via searchParams.get('token') || null, so the page falls back to sessionStorage instead of treating '' as a real query token.

^{Reviewed by Cursor Bugbot for commit 8493aeb. Configure here.}

[greptile-apps]

Greptile Summary

This 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.

• Normalizes an empty ?token= value to null, restoring fallback to the stored invitation token.
• Extends the loading condition to match the invitation query’s token-resolution gate.

Confidence Score: 5/5

The 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.

Important Files Changed

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}