app-registry read/write store split: self-registered MFEs (picker) never appear in the shell

[izzywdev]

@claude — cross-repo delegation from FuzePicker (tracking: FuzePicker Jira FPK-7, epic FPK-6). Please fix the host-backend app-registry split-brain described below and open a PR.

Why

FuzePicker's module-federation remote (picker-app, https://picker.prod.fuzefront.com/remoteEntry.js) is healthy but never renders in the FuzeFront portal — because the shell's app list doesn't contain picker. This is a host-backend registry bug and affects every self-registering MFE, not just picker.

Root cause (in this repo)

Two routers are mounted at /api/v1/app-registry (backend/src/index.ts:287-293): a local-DB adapter (backend/src/routes/appRegistry.ts) first, then a proxy to the applications-service (backend/src/routes/app-registry.ts). The mount comment says the adapter should pass unmatched requests through to the proxy via next() — but the adapter's GET /apps (backend/src/routes/appRegistry.ts:53-73) answers unconditionally from the local apps table and never calls next(). So in prod it shadows the proxy for the one read the shell uses.

Meanwhile MFE self-registration (e.g. FuzePicker's init container: POST /apps, PUT /apps/<slug>, POST /apps/<slug>/activate) only defines GET /apps on the adapter, so those verbs fall through to the proxy → the applications-service registry.

Net: writes land in the applications-service store; the read (frontend/src/platform/appRegistry.tsx:86 → client.listApps({status:'activated'}) → GET /api/v1/app-registry/apps) is served from the host backend's local apps table. Two different stores → self-registered apps are active in the applications-service but absent from what the shell reads → getBySlug('picker') undefined → FederatedAppLoader (frontend/src/components/FederatedAppLoader.tsx:98) errors "App 'picker' not found or not activated" → no UI.

Proposed fix

In backend/src/routes/appRegistry.ts, make GET /apps (and any other reads the shell uses) return next() when the applications-service is configured (e.g. process.env.APPLICATIONS_SERVICE_URL present), so the read path proxies to the same store the write path targets. Keep the local adapter as the CI / no-applications-service fallback only (an explicit flag like APP_REGISTRY_LOCAL_ADAPTER is also fine). This realizes the pass-through the mount comment already promises.

Acceptance criteria

1. With the applications-service configured, GET /api/v1/app-registry/apps returns the applications-service registry contents, not the host backend's local apps table.
2. A self-registered MFE (registered via an init-container to the applications-service, not seeded into the local table) appears in the shell's activated-apps list and mounts at /app/<slug>.
3. Picker renders in the portal at /app/picker.
4. Regression coverage: a unit test asserting the adapter delegates to the proxy when APPLICATIONS_SERVICE_URL is set; an e2e asserting a self-registered remote mounts in the shell.
5. The CI path (no applications-service) still works via the local adapter.

STATE

• Originator: FuzePicker, Jira FPK-7 (epic FPK-6). FuzePicker's half (removing a non-contract nav field from its registration manifest) is already merged: izzywdev/FuzePicker#46.
• Done when: the 5 acceptance criteria pass and a PR is merged here; then picker (and other self-registered MFEs) render in the portal.
• Verify note: live store contents couldn't be inspected externally (registry list is auth-gated 401) — the split is proven from code paths above.
• If blocked, reply here with BLOCKED: <question> + an updated STATE block.

[claude]

Claude finished @izzywdev's task in 0s —— View job

---

I'll analyze this and get back to you.

[izzywdev]

@claude — second, separate FuzeFront-side ask folded into this issue (originator: FuzePicker, story FPK-2 / B4). This is independent of the app-registry split-brain above — please treat it as its own change/PR if cleaner, but it also needs FuzeFront.

Enable "Sign in with Google" from the FuzePicker Chrome extension

The extension now renders a Google button and runs the flow via chrome.identity.launchWebAuthFlow, but the round-trip can't complete until FuzeFront's Google OAuth brokering accepts the extension's redirect URI.

Redirect URI to allow (current unpacked dev build):

https://aflpdefobikbpacogohjgjejahakanii.chromiumapp.org/

Note: for an unpacked extension the ID is path-derived and will change when it's packed/published to the Web Store. To make the whitelisted URI stable across environments, FuzePicker should pin its ID with a manifest key (tracked on the FuzePicker side) and register the resulting https://<stable-id>.chromiumapp.org/. Please allow the dev URI above now, and treat the pattern https://<extension-id>.chromiumapp.org/ as the shape to support.

What the extension calls (see FuzePicker background.js handleFfGoogle):

1. GET /api/v1/security/social/google/start?redirect_uri=<the chromiumapp.org URI> — must accept the redirect_uri param, drive Google's consent with it as the callback, and return to that URI with an opaque ?code=.
2. POST /api/v1/security/session/exchange with { code, redirect_uri } — exchange the code for the session ({ status: 'authenticated', token, user }).

Acceptance criteria (this ask):

1. GET /social/google/start accepts and honours a redirect_uri on the *.chromiumapp.org allowlist (no open-redirect — restrict to that host pattern).
2. POST /session/exchange accepts { code, redirect_uri } and returns an authenticated session for a code minted against that redirect URI.
3. End-to-end: from the extension, clicking "Sign in with Google" → Google consent → returns to the chromiumapp.org URI → session stored; the widget unlocks chat.
4. Until (1)/(2) land, the button still renders and clicking it surfaces a clear error (already the case on the FuzePicker side).

STATE addendum: FuzePicker side is done — the button + chrome.identity flow are merged (izzywdev/FuzePicker#39, #48). This ask is purely the FuzeFront Google-brokering + redirect-URI allowlist.

[claude]

Claude finished @izzywdev's task in 1s —— View job

---

I'll analyze this and get back to you.

[izzywdev]

Fix merged — #547 (squash-merged to master, all gates green including CodeQL).

What landed:

• GET /api/v1/app-registry/apps now delegates to the applications-service proxy by default; the host-backend local-DB adapter is opt-in via APP_REGISTRY_LOCAL_ADAPTER (set in docker-compose.yml + docker-compose.e2e.yml, neither of which runs an applications-service). So the shell's read now comes from the same store writes already land in.
• Keyed on an explicit flag rather than APPLICATIONS_SERVICE_URL, because deploy/helm/fuzefront/templates/backend.yaml does not set that env in prod (the proxy defaults it) — keying on it would have left the adapter shadowing the proxy and the bug intact.
• Added a per-IP rate limit to the read route (resolves a CodeQL js/missing-rate-limiting alert), plus a unit test asserting both directions of the delegation.

Acceptance status:

• (1) ✅ flag unset → reads served by the applications-service (unit-tested).
• (4) ✅ unit test for the delegation decision. The full self-registration e2e was intentionally not added — the e2e stack has no applications-service or registration init-container to register against; standing that up is separate e2e-infra work.
• (5) ✅ CI/local path preserved via the flag.
• (2)/(3) picker renders at /app/picker — runtime outcomes pending the backend release + Argo sync. The registry list is auth-gated (401 externally, per your Verify note), so final confirmation is best done in the portal after this deploys. Leaving this open until the backend rolls and picker is confirmed live.

Cross-repo: originator FuzePicker (FPK-7 / FPK-6); its half is merged (izzywdev/FuzePicker#46).

[izzywdev]

Deployed to prod. The backend rolled onto the fix — fuzefront-backend is now running image ghcr.io/izzywdev/fuzefront-backend:615a3395547d (the #547 merge commit), Argo fuzefront Synced. The read path (GET /api/v1/app-registry/apps) now delegates to the applications-service — the same store self-registration writes to — since prod leaves APP_REGISTRY_LOCAL_ADAPTER unset.

Acceptance criteria 1, 4, 5 are met and the fix is live. The remaining runtime check — picker actually rendering at /app/picker (criteria 2/3) — is auth-gated (the registry list 401s externally, per the issue's own Verify note), so it's best confirmed from the portal. @izzywdev / FuzePicker: please confirm picker (and any other self-registered MFE) now appears in the shell, then this can close.