Probe editor capability endpoints instead of trusting the route list

[jkmassel]

Summary

• Fixes the editor failing to launch on sites where the WP.com REST proxy advertises wp-block-editor/v1/settings in its route list but the actual call 404s — most visibly on JPC sandboxes like protective-artifact-leopard.jurassic.ninja.
• Replaces route-advertisement detection with direct endpoint probes via OkHttp.
• Preserves the Atomic-direct-host protection from Probe direct host for editor capability detection on Atomic sites #22883 with a MUST_NOT_REMOVE pinned test.

Root cause

EditorSettingsRepository.fetchRouteSupport asked apiRoot().get() whether /wp-block-editor/v1/settings was registered. For JPC sites the WP.com proxy advertises /wp-block-editor/v1/sites/<host>/settings in its route list — but hitting that same path returns 404 because the underlying site never registered it. Capability detection said "supported," the editor opened, then the editor's actual settings fetch 404'd.

Confirmed by curl against protective-artifact-leopard.jurassic.ninja: the proxy's ?rest_route=/sites/<host>/ discovery lists the route, both /wp-json/?rest_route=/sites/<host>/wp-block-editor/v1/settings and /wp-block-editor/v1/sites/<host>/settings return 404.

Fix

1. Direct endpoint probes

Replace the route-list scan in EditorSettingsRepository with direct OkHttp probes:

• 2xx / 401 / 403 → Supported (route exists; auth rejected is fine — see Atomic note below)
• 404 → Unsupported
• 5xx / IOException / timeout / missing auth → Inconclusive, leave the cached pref alone

Probes are cancellable (suspendCancellableCoroutine + Call.cancel via invokeOnCancellation) so dangling preloads don't keep sockets open after the scope is torn down.

Each attempt is bounded by a 5s timeout — rather than inheriting the REGULAR client's 60s read timeout — and a transport-level Inconclusive is retried once. Capability detection gates editor preload, so a single network blip would otherwise leave the editor degraded until the next preload runs.

2. Preserve Atomic direct-host routing

GutenbergKit fetches wp-block-editor/v1/settings from the direct host on Atomic sites — it bypasses siteApiRoot for this one endpoint. Capability detection routes the probe accordingly via a forceDirectHost flag at the call site, with a MUST NOT REMOVE comment block citing #22879 / #22883.

The direct-host probe authenticates with the site's application password (Basic), never the WP.com bearer — the direct host doesn't honor the bearer, and we don't want to send WP.com credentials to whatever host wpApiRestUrl points at. Atomic sites that haven't minted an app password yet (e.g. before the headless mint completes) return Inconclusive and leave the cached pref alone until the next preload.

401/403 still counts as Supported here — that's the stale-or-rotated-app-password case, where the route exists but the credential was rejected.

The asymmetry — only settings bypasses, not editor-assets — is also pinned with a test.

3. Probe answer is now authoritative

getSupportsEditorSettingsForSite prefers the probe result once AppPrefs.hasSiteEditorCapabilities returns true, falling back to the legacy EditorSettingsTable row as the first-launch fast-path. Avoids the regression of a stale legacy row overriding a probe that correctly answered false.

4. Shared auth-header helper

buildAuthHeader extracted from GutenbergKitSettingsBuilder into EditorAuthHeaderBuilder so the probe and the editor cannot drift on Bearer-vs-Basic selection.

What we explored

1. Drop the legacy hasExisting SQL row check entirely. ❌ Regresses first-launch UX on sites where the probe hasn't completed yet. Use hasSiteEditorCapabilities as the gate instead.
2. Probe via ReactNativeStore.executeGetRequest. ❌ Has a destructive side-effect of clearing wpApiRestUrl on 404 (ReactNativeStore.kt:232-247), which would re-run discovery just to probe an endpoint.
3. Use wpLoginClient.apiDiscovery() route-list check on the direct host (matches Probe direct host for editor capability detection on Atomic sites #22883 exactly). ❌ Doesn't catch the proxy-advertises-but-doesn't-serve case; probing the actual endpoint is more direct.
4. Fall back to the WP.com bearer for the Atomic direct-host probe when no app password is present. ❌ The direct host doesn't honor the bearer, and it would mean sending WP.com credentials to the direct host. Skip the probe (Inconclusive) until the app password mints instead.
5. Direct OkHttp probe with REGULAR client (5s per-attempt timeout, retry once). ✅ Chosen.

Test plan

• Add a JPC site whose /wp-block-editor/v1/settings returns 404 (e.g. fresh JN sandbox). Open My Site, let the preloader settle, open Site Settings — "Use Theme Styles" should be unsupported. Open the editor — should launch successfully without theme styles, no stall.
• Atomic regression check: sign into automatticwidgets.wpcomstaging.com (or another Atomic site). Confirm Site Settings reports capability correctly and the editor opens — this is the protection from Probe direct host for editor capability detection on Atomic sites #22883 we must not regress.
• WP.com Simple site sanity check: editor still opens with theme styles applied.
• Validate the AI Assistant block still works on Atomic and Simple (third-party blocks gate, separate editor-assets probe).

Unit tests:

• ./gradlew :WordPress:testJetpackDebugUnitTest --tests EditorSettingsRepositoryTest — passes (probe outcomes, Atomic app-password gate, direct-host Basic auth, timeout/retry, cancellation)
• ./gradlew :WordPress:testJetpackDebugUnitTest --tests EditorAuthHeaderBuilderTest — 13 passes
• ./gradlew :WordPress:testJetpackDebugUnitTest --tests GutenbergKitSettingsBuilderTest — passes (regression: existing tests unaffected by helper extraction)
• Consumer tests still green: EditorCapabilityResolverTest, GutenbergEditorPreloaderTest, SiteConnectivityBannerViewModelSliceTest

Related

• Preserves Editor fails to load on Atomic sites when theme-styles capability over-reports availability #22879 / Probe direct host for editor capability detection on Atomic sites #22883 (Atomic direct-host fix)
• Followup to Populate missing wpApiRestUrl during editor preload #22903 (wpApiRestUrl preload recovery — same class of editor-launch-failure root cause)

[dangermattic]

	1 Warning
⚠️	This PR is larger than 300 lines of changes. Please consider splitting it into smaller PRs for easier and faster reviews.

	1 Message
📖	This PR is still a Draft: some checks will be skipped.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Android by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr22921-6591c7d
	Build Number	1488
	Application ID	com.jetpack.android.prealpha
	Commit	6591c7d
	Installation URL	22e62slo8uk6o

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Android by scanning the QR code below to install the corresponding build.

	App Name	WordPress Android
	Build Type	Debug
	Version	pr22921-6591c7d
	Build Number	1488
	Application ID	org.wordpress.android.prealpha
	Commit	6591c7d
	Installation URL	7gugt9sh92sc8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[codecov]

Codecov Report

❌ Patch coverage is 86.72566% with 15 lines in your changes missing coverage. Please review.
✅ Project coverage is 37.35%. Comparing base (6472dd5) to head (519cfc1).
⚠️ Report is 16 commits behind head on release/26.8.

Files with missing lines	Patch %	Lines
...s/android/repositories/EditorSettingsRepository.kt	85.89%	5 Missing and 6 partials ⚠️
...ss/android/repositories/EditorAuthHeaderBuilder.kt	87.87%	4 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff                @@
##           release/26.8   #22921      +/-   ##
================================================
+ Coverage         37.34%   37.35%   +0.01%     
================================================
  Files              2319     2320       +1     
  Lines            124678   124724      +46     
  Branches          16952    16964      +12     
================================================
+ Hits              46556    46595      +39     
- Misses            74361    74362       +1     
- Partials           3761     3767       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.