External login: wait for app-entry-points before the login provider decision

[iOvergaard]

What

The backoffice boot stopped waiting for appEntryPoint extensions to settle before deciding which auth provider to use — a regression introduced in #22522 (the block-permissions PR, which also reworked the extension-initializer lifecycle). On a slow connection an externally registered authProvider (e.g. Umbraco ID) registered inside an app-entry-point's async onInit isn't present yet when the login screen renders, so the login decision is made against a stale registry and the user is dropped on the local login instead of being redirected to the external provider.

Reported from Cloud: intermittent on 3G/incognito, reproducible from v17.4.0 onward (and present on v18 RCs).

Root cause

#22522 changed UmbExtensionInitializerBase.#loaded from a one-shot ReplaySubject to UmbBooleanState(undefined) and removed the await that gated the boot on the app-entry-point initializer. Two problems followed:

1. loaded only became true if (extensions.length > 0), so for a type with zero registered extensions (a default install has no app-entry-points) it never resolved — which is why the boot gate could not simply be re-added (it would hang).
2. With the gate gone, nothing waited for app-entry-points to finish their async onInit before the login provider decision.

Fix

• extension-initializer-base.ts — loaded re-arms to undefined while a processing pass is in flight and resolves to true unconditionally (including zero extensions). .asPromise() skips undefined, so this gates correctly and never hangs.
• app.element.ts — restore the awaited boot gate before routing: await this.observe(entryPointInitializer.loaded).asPromise().

Tests

• Unit (extension-initializer-base.test.ts): loaded must resolve with zero extensions (the hang), and must not report loaded until a late-registered, slow extension has finished instantiating (the race). Both fail on the unfixed code, pass with the fix.
• Acceptance (AuthProviderLateRegistration/): deploys an appEntryPoint that registers an authProvider 1.5s after boot and asserts it is offered on the login screen. Verified RED on the unfixed client build and GREEN on the fixed build against a live instance.

Non-regression

The tests #22522 introduced/reworked all pass with this change: block language-access controller, read-only + read-only-variant guards, and the extension-initializer condition-race tests (64 tests), plus the full extension-api suite (174).

🤖 Generated with Claude Code

[claude]

Claude finished @iOvergaard's task in 8m 54s —— View job

---

PR Review Complete

• Load review skill and standards
• Gather context (diff, changed files)
• Read area-specific documentation
• Review changed files
• Post findings
• Apply labels (area/frontend, category/ux, category/ui)

Review posted as a new comment. Verdict: Approved — one narrow theoretical suggestion about concurrent async callback ordering (not a blocker for the specific fix).

[Copilot]

Pull request overview

Fixes a regression in the backoffice boot sequence where the login provider decision could occur before appEntryPoint extensions (and their async onInit) finished, causing external auth providers to be missed on slow connections.

Changes:

• Adjust UmbExtensionInitializerBase.loaded to re-arm while processing and to resolve even when zero extensions exist.
• Restore an awaited boot gate in UmbAppElement to wait for app-entry-points to settle before routing.
• Add unit + acceptance coverage for late auth provider registration and wire it into Playwright projects.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/Umbraco.Tests.AcceptanceTest/tests/AuthProviderLateRegistration/LateAuthProvider.spec.ts	Adds E2E regression test ensuring a late-registered auth provider appears on the login screen.
tests/Umbraco.Tests.AcceptanceTest/tests/AuthProviderLateRegistration/AdditionalSetup/App_Plugins/LateAuthProvider/umbraco-package.json	Adds a public package fixture that contributes an appEntryPoint for the test.
tests/Umbraco.Tests.AcceptanceTest/tests/AuthProviderLateRegistration/AdditionalSetup/App_Plugins/LateAuthProvider/entry-point.js	Implements delayed authProvider registration inside onInit to reproduce the race.
tests/Umbraco.Tests.AcceptanceTest/playwright.config.ts	Adds a new Playwright project for the unauthenticated late-registration login test.
src/Umbraco.Web.UI.Client/src/libs/extension-api/initializers/extension-initializer-base.ts	Updates loaded semantics to avoid hangs (zero extensions) and to re-arm while a pass is running.
src/Umbraco.Web.UI.Client/src/libs/extension-api/initializers/extension-initializer-base.test.ts	Adds unit tests for loaded resolving with zero extensions and waiting for late/slow instantiation.
src/Umbraco.Web.UI.Client/src/apps/app/app.element.ts	Waits for app-entry-points to finish initializing before routing/login provider decision.

[claude]

PR Review

Target: origin/release/17.5.0 · Based on commit: 102e4aa80b11f9bc96ea47ead373cca5ea0402c6

Restores the app-entry-point boot gate removed in #22522, fixing the race where externally registered authProvider extensions were absent when the login screen decided which provider to use. The two-part fix — unconditional loaded resolution including zero-extension case, plus re-arming loaded to undefined during each processing pass — correctly handles both the zero-extension hang and the stale-true resolution.

• Modified public API: UmbExtensionInitializerBase.loaded behavioral change — observable now cycles undefined → true on each extension processing pass (previously only emitted once and only when extensions.length > 0). Type is unchanged: Observable<boolean | undefined>.
• Affected implementations (outside this PR): Two existing asPromise() consumers of .loaded — both in app.element.ts — handle the re-arm semantics correctly and are unaffected.

---

Suggestions

• extension-initializer-base.ts:27–51: The re-arm prevents a stale true from an earlier pass tricking consumers — but only if the newer pass completes before the older one does. If two passes overlap (the registry emits a new extension list while a previous Promise.all is still in flight), the older pass completing fires setValue(true) while the newer pass is still processing, potentially resolving a consumer's asPromise() prematurely. This cannot happen in the specific boot scenario being fixed (one stable batch from registerPublicExtensions()), so it is a narrow theoretical edge case — not a blocker, just worth noting if appEntryPoint extensions are ever registered dynamically during boot.

---

Approved

This looks good to be merged as-is. Root cause analysis is thorough, both unit regression tests cover the exact failure modes (zero-extension hang and late-extension race), and the acceptance test provides an end-to-end guard documented as verified red-on-unfixed / green-on-fixed. Recommend a manual sanity check on the login flow before merging.

[iOvergaard]

Addressed the review suggestions in c566dd0:

1. Playwright glob — narrowed testMatch to AuthProviderLateRegistration/**/*.spec.ts so the entry-point.js ESM fixture under AdditionalSetup isn't picked up as a test file. Matches the other AdditionalSetup-bearing projects.
2. Concurrent passes — loaded now only settles for the latest processing pass (monotonic pass id), so a slow earlier pass can't unblock waiters before the newest set of extensions has finished instantiating.
3. Throwing instantiateExtension — switched to Promise.allSettled so a rejection can't leave loaded stuck at undefined (which would hang the boot gate); failures are logged rather than swallowed. Mirrors how #loadedGuard already handles its awaits.

Still green: 175 extension-api unit tests, and the AuthProviderLateRegistration acceptance spec passes (and confirmed RED on the unfixed client build).

[leekelleher]

Tested out, works as described. 🚀