## Experiment — not for merge as-is
A perf experiment for discussion. Opening as a draft to gather feedback
and let CI run.
## Problem
On a warm (returning) load, the app gate
([`MinimalMetadataGater`](https://github.com/twentyhq/twenty/blob/main/packages/twenty-front/src/modules/metadata-store/components/MinimalMetadataGater.tsx))
blocks first paint until **both** object/view metadata **and**
`currentUser` are ready.
The metadata store is already cache-first: it persists each entity
(including `status: 'up-to-date'`) to `localStorage` with `getOnInit`,
opens from cache, and revalidates in the background via collection
hashes. 👏
`currentUser` (and `currentWorkspace` / `currentWorkspaceMember` /
`currentUserWorkspace`) is **not** — it lives in an in-memory atom, so
every load fires a blocking `GetCurrentUser` round-trip before the gate
opens. That round-trip is the one remaining network hop on the warm-load
critical path; everything else the first screen needs is already in
`localStorage`.
## Approach
Generalize the pattern the metadata store already proves out, to the
user bootstrap — **without adding any new `useEffect`**:
- Persist the four bootstrap atoms (`currentUser`, `currentWorkspace`,
`currentWorkspaceMember`, `currentUserWorkspace`) via the existing
`createAtomState({ useLocalStorage, localStorageOptions: { getOnInit:
true } })`.
- The gate opens from cache on its own: the existing
`IsMinimalMetadataReadyEffect` already derives readiness from the
`currentUser` atom alongside metadata status, so persisting the atoms is
enough — no new effect.
- Keep firing `GetCurrentUser` (now `network-only`, no longer skipped
when a user is present) so it **revalidates in the background** and the
existing write-through effect updates the atoms with the fresh result.
- Clear the cached identity on sign-out by adding the four keys to
`clearSessionLocalStorageKeys` (already invoked by `clearSession`, which
then hard-reloads).
Net effect: warm loads no longer wait on `GetCurrentUser`; the shell
paints from cache and corrects within one round-trip. Cold loads (no
cache) are unchanged.
## Risks to validate
- **Permission staleness** — `currentUserWorkspace` carries
`objectsPermissions` / `permissionFlags`. Cache-first means a brief
stale-permission window before revalidation. Not a security boundary
(the server authorizes every request), but it can momentarily show a
menu item the user no longer has; worst case it 401s and corrects on the
next paint.
- **Feature-flag / workspace staleness** —
`currentWorkspace.featureFlags` may be one round-trip stale on warm
load.
- **`X-Schema-Version` header** — sourced from
`currentWorkspace.metadataVersion`; caching it actually makes the header
*consistent* with the already-cached metadata rather than absent, but
worth confirming against the server's mismatch handling.
- **Test isolation** — these atoms now persist; tests relying on the
default `null` could see cross-test leakage if `localStorage` isn't
reset. The directly-affected suites pass locally (`useAuth`,
`useDefaultHomePagePath`, `useSetNextOnboardingStatus`); CI's full run
is the real check.
## Validation
- [ ] Full CI (types/lint/unit) green
- [ ] Manual: throttle network, hard-reload a logged-in workspace,
confirm the shell paints before `GetCurrentUser` resolves and that fresh
data writes through
- [ ] Sign out → sign in as a different user on the same browser;
confirm no stale identity flashes
Félix Malfait
f869ce87b1