Rate limit stopping data

[2ndtlmining]

Running into rate limits stop data from showing:

[2ndtlmining]

Likely fixed by #218 — please confirm at next QA

#218 (merged) root-caused what was almost certainly this. The short version: the rate limit was presenting as a CORS error, which is why it was hard to pin down.

Measured 2026-09-11:

explorer.runonflux.io      -> HTTP 429, Retry-After: 31, NO CORS headers
explorer.app.runonflux.io  -> HTTP 200, access-control-allow-origin: *

A rate-limited response omits Access-Control-Allow-Origin, so the browser cannot surface the 429 to JS and reports "blocked by CORS policy" instead. Every one of those console errors was a rate limit wearing a CORS costume — which is exactly the shape of "data stops showing with nothing obviously wrong".

#218 routes all 8 client explorer call sites through a host pool with bidirectional failover, benching a throttled host (honouring Retry-After) so subsequent calls skip it rather than re-attempting it and making the limit worse. The Rust scanner got the same treatment: it previously backed off up to 62 seconds against a single host, which is why a Chain Activity cold start never finished.

What is NOT covered

The failover is explorer-only. The client also hits:

host	references	failover
api.runonflux.io	10	none
stats.runonflux.io	8	none
explorer.runonflux.io	4 (2 are <a href> links)	yes, #218

Both currently return HTTP 200 with proper CORS headers, so neither is throttling right now — but neither has a fallback if that changes.

Worth noting the original suggestion on this thread that any Flux node serves the same API. That is true and would make a genuine pool possible for api.runonflux.io, but it needs a node list, health checking and TLS-on-IP handling, so it is its own piece of work rather than a follow-on.

Please confirm whether the symptom persists during the next QA pass. If it does, the console will now say which host and why, instead of blaming CORS.