fix(app-registry): delegate registry reads to the applications-service so self-registered MFEs render (#533) - #547
Merged
Conversation
…e proxy (#533) The host backend's local-DB adapter answered GET /apps unconditionally, shadowing the proxy so the shell read a different store than writes land in — self-registered MFEs (e.g. picker) were active in the applications- service but absent from the shell. Delegate by default; keep the local adapter as an opt-in CI/no-service fallback (APP_REGISTRY_LOCAL_ADAPTER).
…plications-service) (#533)
…ations-service) (#533)
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
…sing-rate-limiting) (#533)
Contributor
Automated code review (gate-code-review)Credit balance is too low Report-only — this check never blocks merge. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #533 — the host-backend app-registry read/write split-brain that kept every self-registering MFE (FuzePicker's
picker, and others) out of the shell.Root cause
Two routers mount at
/api/v1/app-registry(backend/src/index.ts): the local-DB adapter (routes/appRegistry.ts) first, then the applications-service proxy (routes/app-registry.ts). The mount comment says the adapter should pass unmatched requests through to the proxy vianext()— butGET /appsanswered unconditionally from the localappstable and never callednext(), so it shadowed the proxy for the one read the shell uses.Meanwhile self-registration (
POST /apps,PUT /apps/<slug>,POST /apps/<slug>/activate) is only defined on the adapter asGET /apps, so those verbs already fall through to the proxy → the applications-service store. Net: writes landed in the applications-service; the read came from the host backend's local table. Two stores → self-registered apps never appear in the shell →FederatedAppLoadererrorsApp 'picker' not found or not activated.Fix
backend/src/routes/appRegistry.ts:GET /appsnow delegates to the proxy by default (return next()), so the read comes from the same store writes target. The local adapter becomes an opt-in CI / no-applications-service fallback, enabled withAPP_REGISTRY_LOCAL_ADAPTER=1.Why an explicit flag and not
APPLICATIONS_SERVICE_URL: the issue suggested keying onAPPLICATIONS_SERVICE_URL, butdeploy/helm/fuzefront/templates/backend.yamldoes not set that env — the proxy defaults it tohttp://fuzefront-applications:3003. So keying on it would leaveprocess.env.APPLICATIONS_SERVICE_URLundefined in prod and the adapter would keep shadowing the proxy — the bug would survive. Inverting the default (delegate unless explicitly told to use the local table) is correct in prod with no env change, and the issue explicitly allows the flag form.docker-compose.yml+docker-compose.e2e.yml: setAPP_REGISTRY_LOCAL_ADAPTER=1on the backend — neither stack runs an applications-service, so they keep serving reads from the local table (criterion 5).Tests
backend/tests/app-registry-delegation.test.ts(pure unit, axios + db + auth mocked):GET /appsforwards to the applications-service (returns the proxy'spicker, not the local table; token forwarded verbatim to/api/v1/app-registry/apps?status=activated).appstable, proxy never called.Acceptance criteria
GET /api/v1/app-registry/appsreturns the applications-service contents — covered by the unit test and the inverted default./app/picker— runtime outcomes that this read-path fix enables; verifiable in prod after deploy.docker-compose.e2e.yml) contains no applications-service and no registration init-container, so there's nothing to register against. Standing that up is a separate e2e-infra change; flagged rather than faked.Cross-repo
Originator: FuzePicker (Jira FPK-7, epic FPK-6). FuzePicker's half is already merged (izzywdev/FuzePicker#46). After this merges and releases, picker and other self-registered MFEs render in the portal.
🤖 Generated with Claude Code