Performance: Parallelize independent boot API requests (server status/config + public extensions)

[iOvergaard]

What

Two boot-sequence requests that were awaited serially, but are independent, now run in parallel:

1. UmbServerConnection.connect() — server/status and server/configuration were awaited one after the other. They share no data, so they now run via Promise.allSettled. allSettled (not Promise.all) is deliberate: both are required for the backoffice to function, so any failure is collected and rethrown for the existing error-page handling, and a rejection in one call never leaves the other's rejection unhandled.
2. App startup (app.element.ts) — public (login) extension registration was fully awaited before the auth flow. It's now kicked off up front and awaited only just before routing (where the login screen actually needs it), so its manifest/public fetch overlaps the auth/token request.

Why

Each serialized hop is one management-API round-trip. That's negligible on localhost (~14 ms) but ~150 ms each on high-latency hosts (e.g. Umbraco Cloud), where they sit on the critical boot path before the backoffice is interactive. Tracing a document-workspace load on Cloud showed these as a serial chain (status → configuration → … → public extensions), so parallelizing the independent links shortens time-to-interactive on first paint with no behavioural change.

Notes

• No functional change: same requests, same error handling (connect failures still surface on the app error page; registerPublicExtensions uses tryExecute, which resolves rather than rejects).

How to test

1. Run the backoffice and confirm normal startup + login still work.
2. (Optional) Throttle network or test on a high-latency host and compare the boot waterfall — server/status and server/configuration should now overlap, as should manifest/public with the token request.

🤖 Generated with Claude Code

[claude]

Claude finished @iOvergaard's task in 4m 31s —— View job

---

PR Review

Target: origin/v17/dev · Based on commit: 52bfbad9

Parallelizes two independent boot-sequence request pairs: server/status + server/configuration now run via Promise.allSettled, and manifest/public (public extension registration) is kicked off before the auth flow and awaited just before routing.

• Modified public API: UmbServerConnection.connect() — error type changes from a single raw error to AggregateError when both parallel calls fail
• Other changes: Boot sequence timing improved; no functional behavior change for callers

---

Suggestions

• server-connection.ts:49–55: When #setStatus() resolves but #setServerConfiguration() rejects, this.#isConnected is already set to true inside #setStatus() before connect() throws. In practice this is harmless — the object is always used as await new UmbServerConnection(...).connect() so a throw means the reference is discarded — but it's a subtle partial-state observable on the isConnected stream. If you want to make the invariant airtight, you could defer this.#isConnected.setValue(true) until after both promises settle successfully (e.g. move it into connect() after the allSettled check). Fix this →

• app.element.ts:262–265: If clearTokenStorage() or #setAuthStatus() throws before await registerPublicExtensions is reached, the registration promise floats in the background while the error page renders. tryExecute means it resolves rather than rejects, so there's no unhandled-rejection concern — just a redundant network request completing after the page is in an error state. Worth a comment noting this is intentionally fire-and-forget in the error path, or prefixing with void at the point of use to make the intent explicit.

---

Approved with Suggestions for improvement

Good to go, but please carefully consider the importance of the suggestions.

The parallelization logic is sound: Promise.allSettled is the right primitive here (vs Promise.all) since both calls must succeed and neither should leave the other's rejection unhandled. The "fire and await later" pattern for public extensions is clean and the await position is correct (after auth, before routing). No breaking changes.

[Copilot]

Pull request overview

Parallelizes two independent boot-time API call chains in the backoffice to reduce time-to-interactive on high-latency hosts, without altering observable behaviour or error handling.

Changes:

• UmbServerConnection.connect() runs #setStatus() and #setServerConfiguration() via Promise.allSettled, then rethrows a single error or an AggregateError if any failed.
• App startup kicks off registerPublicExtensions() before the auth flow and only awaits it just before routing, overlapping it with the token request.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/Umbraco.Web.UI.Client/src/packages/core/server/server-connection.ts	Run status and configuration fetches concurrently; aggregate errors so neither rejection is lost.
src/Umbraco.Web.UI.Client/src/apps/app/app.element.ts	Start public extension registration eagerly and await it just before routing, in parallel with auth init.

[iOvergaard]

Thanks for the review.

• Suggestion 1 (partial isConnected state) — applied in 58e22c9: moved isConnected.setValue(true) out of #setStatus() into connect() after the allSettled check, so the observable only fires once both calls succeed.
• Suggestion 2 (floating registerPublicExtensions in the error path) — left as-is intentionally. registerPublicExtensions goes through tryExecute, which resolves rather than rejects, so there's no unhandled rejection — just a redundant request finishing after the error page renders, which is harmless. The suggested void-at-use doesn't apply since it's genuinely awaited in the success path; the float only occurs if auth throws first. Happy to add a clarifying note if preferred.

[AndyButland]

All looks good @iOvergaard. Code changes make sense to consolidate the #isConnected setting only after both requests succeed, and the parallelisation makes sense.

I've verified login, backoffice rendering and noted via dev tools that the configuration and status request now no longer run sequentially.