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
Found in the Brian/Simon multi-tenant workspace pair-debug session, 2026-08-03.
The gate
apps/users/auth_views.py:117-131 — me_view calls _atry_resolve_provideronly when not onboarding_complete. And _aonboarding_complete (:83-89) is True if the user has any non-archived, connection-backed membership.
So the one hook that could re-validate upstream access on a routine request is dead for exactly the population that needs it: anyone who has ever successfully onboarded. Results are additionally cached 30s (:42, :113-115). This is a lazy onboarding hook mislabelled as a refresh path.
What does re-validate (and why it is not enough)
To be precise — and correcting an initial overstatement of "nothing re-validates":
apps/users/views.py:84-120tenant_list_view (GET /api/auth/tenants/) does re-resolve all three providers, behind a 1-hour TTL (views.py:31). It also archives vanished tenants.
But it fires only when the SPA hits that endpoint, which happens in CreateWorkspaceModal and WorkspaceDetailPage — and is memoized per page session by frontend/src/api/userTenantsCache.ts. It is never on the chat, query, or artifact path.
apps/users/signals.py:125-145 resolves on OAuth login, but only for the provider just used — so logging in via Google/GitHub/password re-validates nothing. This is why Brian logged back in via a different provider and kept access.
So the accurate framing is: there is no routine upstream re-validation on the paths users actually exercise.
Related
Refresh user's tenant list #173 asks for periodic/on-login refresh — this is the "on access" half and identifies why the existing hook doesn't fire.
The fail-open-on-401 issue is a prerequisite: making this hook fire more often does nothing until a 401 is treated as revocation, because both paths swallow the raise.
Suggested direction
Either drop the onboarding_complete condition (accepting the upstream call cost, with a sensible TTL like tenant_list_view's), or move re-resolution to a periodic task per #173 and keep me_view cheap. The latter is probably right; the point of this issue is that the current hook gives a false sense that login-time revalidation exists.
Found in the Brian/Simon multi-tenant workspace pair-debug session, 2026-08-03.
The gate
apps/users/auth_views.py:117-131—me_viewcalls_atry_resolve_provideronly whennot onboarding_complete. And_aonboarding_complete(:83-89) isTrueif the user has any non-archived, connection-backed membership.So the one hook that could re-validate upstream access on a routine request is dead for exactly the population that needs it: anyone who has ever successfully onboarded. Results are additionally cached 30s (
:42,:113-115). This is a lazy onboarding hook mislabelled as a refresh path.What does re-validate (and why it is not enough)
To be precise — and correcting an initial overstatement of "nothing re-validates":
apps/users/views.py:84-120tenant_list_view(GET /api/auth/tenants/) does re-resolve all three providers, behind a 1-hour TTL (views.py:31). It also archives vanished tenants.CreateWorkspaceModalandWorkspaceDetailPage— and is memoized per page session byfrontend/src/api/userTenantsCache.ts. It is never on the chat, query, or artifact path.apps/users/signals.py:125-145resolves on OAuth login, but only for the provider just used — so logging in via Google/GitHub/password re-validates nothing. This is why Brian logged back in via a different provider and kept access.So the accurate framing is: there is no routine upstream re-validation on the paths users actually exercise.
Related
Suggested direction
Either drop the
onboarding_completecondition (accepting the upstream call cost, with a sensible TTL liketenant_list_view's), or move re-resolution to a periodic task per #173 and keepme_viewcheap. The latter is probably right; the point of this issue is that the current hook gives a false sense that login-time revalidation exists.