Fix false "XML-RPC Disabled" card on rate-limited self-hosted sites - #23120
Merged
adalpari merged 3 commits intoJul 21, 2026
Conversation
App-password self-hosted sites could wrongly show the "XML-RPC Disabled" My Site card even when XML-RPC is enabled, because a transient HTTP 429 (rate-limit) was treated as "XML-RPC unavailable" in two places: 1. Discovery succeeds at login but the authenticated XML-RPC fetch 429s: fetchSitesXmlRpcFromApplicationPassword fell back to WPAPI and dropped the already-verified endpoint. Now it persists the verified endpoint on the WPAPI-stored site via the new URL-keyed updateXmlRpcUrlForWPAPISite. 2. Discovery itself 429s: DiscoveryXMLRPCClient.listMethods swallowed the 429 as an empty response, so discovery reported MISSING_XMLRPC_METHOD / NO_SITE_ERROR, indistinguishable from a genuinely disabled site. (Note: Volley's ClientError for 429 extends ServerError, so the 429 must be handled inside the ServerError branch.) A new DiscoveryError.RATE_LIMITED is now thrown and propagated through verifyXMLRPCUrl / checkXMLRPCEndpointValidity. The card slice no longer shows the warning optimistically: attemptXmlRpcRediscovery surfaces the card only on a definitive-negative discovery result (NO_SITE_ERROR, MISSING_XMLRPC_METHOD, XMLRPC_BLOCKED, XMLRPC_FORBIDDEN); transient/unknown failures keep it hidden and re-check on the next refresh. It also bails on the first 429 instead of firing a burst of discovery requests that re-trigger the rate limit. Genuine detection is preserved: a truly disabled site (clean 404/405/403, no 429) still surfaces the warning. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Collaborator
Generated by 🚫 Danger |
Contributor
|
|
Contributor
|
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## trunk #23120 +/- ##
==========================================
+ Coverage 37.68% 37.71% +0.02%
==========================================
Files 2343 2343
Lines 127342 127365 +23
Branches 17658 17667 +9
==========================================
+ Hits 47995 48033 +38
+ Misses 75414 75394 -20
- Partials 3933 3938 +5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
adalpari
marked this pull request as ready for review
July 21, 2026 09:11
adalpari
enabled auto-merge (squash)
July 21, 2026 11:25
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
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.


Description
App-password self-hosted sites could wrongly show the "XML-RPC Disabled" My Site card even when XML-RPC is actually enabled. The root cause: a transient HTTP 429 (rate-limit) from the site's
xmlrpc.phpwas treated as "XML-RPC unavailable" in two places.1. Discovery succeeds at login, then the authenticated XML-RPC fetch 429s.
SiteStore.fetchSitesXmlRpcFromApplicationPasswordfell back to the WPAPI path and discarded the already-verified endpoint. It now persists the verified endpoint on the WPAPI-stored site via the new URL-keyedSiteSqlUtils.updateXmlRpcUrlForWPAPISite(ORIGIN_WPAPI-scoped, mirroringupdateWpApiRestUrlForWPAPISite).2. Discovery itself 429s.
⚠️ Gotcha: Volley's
DiscoveryXMLRPCClient.listMethodssilently swallowed the 429 as an empty response, so discovery reportedMISSING_XMLRPC_METHOD/NO_SITE_ERROR— indistinguishable from a genuinely disabled site. A newDiscoveryError.RATE_LIMITEDis now thrown on 429 and propagated throughverifyXMLRPCUrl/checkXMLRPCEndpointValidity.ClientError(429) extendsServerError, so the 429 has to be handled inside theServerErrorbranch, before the 405 check.Card behavior.
ApplicationPasswordViewModelSliceno longer shows the warning optimistically.attemptXmlRpcRediscoverysurfaces the card only on a definitive negative discovery result (NO_SITE_ERROR,MISSING_XMLRPC_METHOD,XMLRPC_BLOCKED,XMLRPC_FORBIDDEN); transient/unknown failures keep it hidden and re-check on the next refresh. It also bails on the first 429 instead of firing a burst of discovery requests that re-trigger the rate limit.Genuine detection is preserved: a truly disabled site (clean 404/405/403, no 429) still surfaces the warning.
Testing instructions
XML-RPC card is not falsely shown on a rate-limited site:
xmlrpc.phpwith HTTP 429).Genuine "disabled" detection still works: