Skip to content

fix(rpc-client): treat Cloudflare 5xx (521-524) as retryable connection errors#520

Open
elina-chertova wants to merge 1 commit into
masterfrom
alert-fix/SgDu2H-svm-bnb-522-crash
Open

fix(rpc-client): treat Cloudflare 5xx (521-524) as retryable connection errors#520
elina-chertova wants to merge 1 commit into
masterfrom
alert-fix/SgDu2H-svm-bnb-522-crash

Conversation

@elina-chertova

Copy link
Copy Markdown
Contributor

Problem

The svm-bnb_No_Dumper_Data alert fired: dump-svm-bnb-0 (ns solana-archive) crash-looped (exit 1) with call failed with unserializable error originating from a transient Cloudflare 522 returned by the sole endpoint rpc.svmbnbmainnet.soo.network.

Root cause is in RpcClient.isConnectionError (util/rpc-client/src/client.ts): it classifies 408/429/502/503/504 as retryable connection errors but omits Cloudflare-origin 521-524 — even though @subsquid/http-client's own isRetryableError already treats 521-524 as retryable. A 522 is therefore classified fatal, thrown out of the worker-thread stream, and crashes the dumper (the opaque unserializable error is the error then failing structured-clone at the worker boundary). 429 is in the set, so the post-restart pod stalls-and-retries rather than crashing.

Fix

Add 521/522/523/524 to the retryable-status switch in isConnectionError, so a transient Cloudflare 5xx is backed off and retried in-worker instead of escaping as fatal.

Relationship to #509

Complementary, not duplicate. This PR stops a 522 before it escapes the worker (retried in-place). #509 hardens serializeError so any error that does escape the worker boundary is delivered as a classifiable error rather than an opaque unserializable error. Both are needed for full defence-in-depth; this PR is the primary fix for the observed 522 crash.

Test

Adds util/rpc-client/src/client.test.ts — unit-tests isConnectionError across statuses (RED before fix on 521-524, GREEN after). vitest --run: 3/3 passing. Rush change file added; rush update lockfile churn verified deterministic/CI-consistent.

Operational follow-up (escalate)

The endpoint is up + archival (direct probe: HTTP 200, slot 74143670; burst of 10 concurrent full-block reqs all 200), but the dumper's client is being 429-throttled specifically (requests_served_total = 0 for 3h+). The code fix stops the crash-loop but does not restore throughput — the single rpc.svmbnbmainnet.soo.network endpoint (stride_concurrency: 10, no rate limit configured) needs a provider-side rate-limit / additional endpoint. Escalate to the infra/provider owner.

…on errors

A transient Cloudflare-origin 522 from the sole SVM-BNB endpoint crashed the
dumper (exit 1) because RpcClient.isConnectionError recognized 408/429/502/503/504
as retryable but not 521-524. The 522 was classified fatal and thrown, whereas the
http-client's own isRetryableError already treats 521-524 as retryable. Add them so
transient upstream Cloudflare errors are backed off and retried instead of crashing
the stream. Complements #509 (worker-thread error serialization).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant