fix(editor): stop persisting a WP.com proxy root as the site's REST API root

[dcalhoun]

TL;DR

Fix CMM-2383. The editor failed to load with rest_no_route on some Atomic sites because their stored REST API root was a WP.com proxy URL that already contained the wp/v2/sites/<id> namespace, so every request carried the namespace twice. While the erroneous URL surfaced as an editor failure, the impact is far wider, albeit latent.

Description

Symptom

Every editor dependency 404s with rest_no_route, and the editor never loads:

https://public-api.wordpress.com/wp/v2/sites/256930037/wp/v2/types?context=view
https://public-api.wordpress.com/wp/v2/sites/256930037/wp/v2/themes?context=edit&status=active
https://public-api.wordpress.com/wp/v2/sites/256930037/wp-block-editor/v1/settings

Those decompose exactly as siteApiRoot + path, with siteApiNamespace empty. The root already embeds wp/v2/sites/<id>, so GutenbergKit appends an already-namespaced path to an already-namespaced root.

Root cause

SiteModel.getWpApiRestUrl() returned a synthesized WP.com proxy root whenever the site read as WP.com Simple, so callers would "get the correct endpoint without needing site-type checks". But that value isn't the same kind of URL as a stored one, and every reader treats the property as a bare direct-host root. Introduced in #22765.

The value also didn't stay derived. The generated WellSql mapper reads the getter — cv.put("WP_API_REST_URL", item.getWpApiRestUrl()) — and insertOrUpdateSite writes the full row on insert, while its update path excludes the column. So a site added to the app while it was still Simple had the proxy root written into WP_API_REST_URL at insert and kept it permanently; no later sync could correct it.

Once such a site transferred to Atomic and acquired an application password, GutenbergKitSettingsBuilder took the direct-host branch, used the stored proxy root, and set an empty namespace.

Why it looked user-specific

The row is poisoned at insert, so only on the device that added the site while it was Simple — in practice the device that created it. A device that first sees the site after the Atomic transfer inserts it with a null column and works fine. That's why the reported site failed for its creator and worked for an administrator added later, and why pull-to-refresh never helped.

The application password isn't a cause; it's the switch that exposes the already-poisoned column by flipping shouldUseWPComRestApi to false.

Scope beyond the editor

Everything that reads wpApiRestUrl as a direct-host root was affected: WpApiClientProvider.getApplicationPasswordClient / getDirectHostApiUrlResolver, WpServiceProvider (the wordpress-rs Posts list), ApplicationPasswordsNetwork, and ApplicationPasswordValidator. That accounts for the Posts-list failures and the "Unable to connect to your site" banner seen alongside the editor error.

The change

• SiteModel.getWpApiRestUrl() returns the stored value only. No caller needed the synthesis: WP.com-routed traffic goes through WpComUrlResolver (WpApiClientProvider.getWpApiClient / getApiUrlResolver) or wpComRestClient (ReactNativeStore dispatches on isUsingWpComRestApi). Every reader of the property wants a direct-host root, and each pairs it with a ${url}/wp-json fallback — though note that five fluxc readers use a bare ?:, so the fallback doesn't fire for an empty string (see follow-ups).
• SiteSqlUtils.updateWpApiRestUrl refuses WP.com proxy URLs. It is the sole writer of the column, so rejecting there covers every reader at once rather than each having to recognise the shape. The predicate lives in a new WPComApiProxy and is shared with the migration, so a value the writer rejects can't survive in an older row.
• The stored root is normalized to a trailing slash. api-fetch's createRootURLMiddleware strips a path's leading slash before concatenating onto the root, and buildEditorAssetsEndpoint concatenates with no separator, so a slash-less root yields …/wp-jsonwp/v2/types — the same failure class. WpApiClientProvider builds exactly such roots and they reach the column via app-password login. Roots carrying a query string are the plain-permalink ?rest_route= form and are left alone.
• DB migration 213 nulls WP_API_REST_URL values matching https://public-api.wordpress.com/wp/v2/sites/%. Required: existing installs are already poisoned and nothing else rewrites that column. The prefix match is safe — only the removed synthesizer produced that shape.
• GutenbergKitSettingsBuilder rejects a proxy root in the direct-host branch and falls back to the site's own host, logging when it does. A backstop, but this is the layer that knows the root and namespace have to agree.
• resolveApiTransport now derives root, namespace and auth header together, since they're only valid as a set.
• Diagnostics (first commit): the editor logs how it resolved its REST root plus the site classification, tagged by ConfigSource (preloader vs editor), and SiteSqlUtils logs the value the mapper is about to persist on insert. These were how the origin was found and are worth keeping as a canary.

Testing instructions

The reproduction needs the site to be created in the app — that's the step that inserts the poisoned row.

Reproduce on trunk first:

1. In the app, create a new WordPress.com site (free/Simple is fine).
2. Purchase a plan
3. Transfer the site to Atomic (the web's Hosting Features UI works).
   1. https://wordpress.com/hosting-features/<site_origin_or_id>
   2. Click the site name in the sidebar to reveal the activation flow
   3. Proceed to Activate hosting features
4. Back in the app, do not open the editor. Instead, switch to a different site and perform a pull-to-refresh gesture. Switching back to the created site and pull-to-refresh again.
5. Visit the Posts list to trigger the headless mint of an application password, and a "Unable to connect to your site" banner often appears.
6. Open the editor.

• Verify it fails with "Failed to load editor — rest_no_route", and that requests go to https://public-api.wordpress.com/wp/v2/sites/<id>/wp/v2/...

Then install this branch over it (do not clear app data — the migration is the point):

7. Launch the app.

• Verify the log shows Upgrading database from version 212 to 213
• Verify the site's WP_API_REST_URL is now null, and that legitimate …/wp-json/ roots on other sites are untouched:

  adb exec-out run-as com.jetpack.android.prealpha cat databases/wp-fluxc > /tmp/wp-fluxc.db
  sqlite3 /tmp/wp-fluxc.db "SELECT SITE_ID, URL, IS_WPCOM, IS_WPCOM_ATOMIC, WP_API_REST_URL FROM SiteModel;"
  

8. Open the editor on the transferred site.

• Verify it loads, with theme styles applied
• Verify the log shows root=https://<site>/wp-json/, and no rest_no_route

Regression checks:

9. Open the editor on a WordPress.com Simple site.

• Verify wpcomRest=true root=https://public-api.wordpress.com/ and a sites/<id>/ namespace — unchanged behaviour

10. Open the editor on a self-hosted site and on a Jetpack site.

• Verify both still load

Verified on device

Both previously-broken Atomic sites now load. The migration cleared 8 poisoned rows and left 3 legitimate roots untouched. A Simple site and a private Atomic site that already worked were unchanged.

Known gaps, deliberately left out

Both are pre-existing, neither is made worse here, and each wants its own tests and blast-radius review.

• clearWpApiRestUrl writes "", not NULL. Five fluxc readers use a bare ?:, so an empty string reads as "present" and resolves to a host-less base URL. Its one caller is removeApplicationPassword, so the trigger is narrow — but it is sticky, because ReactNativeStore treats non-null as "already discovered" and therefore stops re-running discovery that would otherwise heal the row.
• The editor resolves its transport from the SiteModel serialized into its intent, while the preloader deliberately re-reads from the store (GutenbergEditorPreloader does getSiteByLocalId(...) ?: site precisely because provisioning mints credentials mid-flight). A snapshot taken before provisioning yields the WP.com bearer path where the preloader used the direct host. Both transports work, so the realistic cost is a preload cache miss rather than a failure — the ConfigSource tagging on the routing log exists to measure whether it happens in the field before changing behaviour.

Related

• Editor fails to load when a cached capability flag is stale GutenbergKit#602 shares the rest_no_route string but are a different bug — a well-formed request to a route that genuinely doesn't exist. Its fix degrades optional dependencies, so it would not have helped here: /wp/v2/types and /wp/v2/themes are required.
• Private sites: expose a minimal REST API index for auth discovery Automattic/jetpack#51848 makes REST auto-discovery possible on private Atomic sites. Not required for this fix — a cleared row falls back to ${site.url}/wp-json/, which works — but it's what will let discovery actually populate the column for those sites.

🤖 Generated with Claude Code

https://claude.ai/code/session_017aCE7dERu43yYPzoxrqeq4

[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	pr23301-b338e94
	Build Number	1498
	Application ID	org.wordpress.android.prealpha
	Commit	b338e94
	Installation URL	1jpi7tfvd1r8g

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 Jetpack Android by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Android
	Build Type	Debug
	Version	pr23301-b338e94
	Build Number	1498
	Application ID	com.jetpack.android.prealpha
	Commit	b338e94
	Installation URL	4e4u86inr9dbo

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

[wpmobilebot]

🤖 Build Failure Analysis

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

[codecov]

Codecov Report

❌ Patch coverage is 83.82353% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.06%. Comparing base (4e4662a) to head (b338e94).

Files with missing lines	Patch %	Lines
...word/ApplicationPasswordAutoAuthDialogViewModel.kt	0.00%	6 Missing ⚠️
...ss/android/ui/posts/GutenbergKitSettingsBuilder.kt	93.33%	0 Missing and 3 partials ⚠️
...org/wordpress/android/fluxc/model/WPComApiProxy.kt	0.00%	0 Missing and 1 partial ⚠️
...rdpress/android/fluxc/persistence/WellSqlConfig.kt	50.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##            trunk   #23301      +/-   ##
==========================================
+ Coverage   38.04%   38.06%   +0.01%     
==========================================
  Files        2353     2354       +1     
  Lines      128959   129005      +46     
  Branches    17976    17981       +5     
==========================================
+ Hits        49068    49103      +35     
- Misses      75871    75878       +7     
- Partials     4020     4024       +4     

☔ View full report in Codecov by Harness.
📢 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.