docs: note public testnet RPC method differences across follow endpoints - #373
Conversation
|
Thanks for turning this around so quickly, and for splitting follow-sync from application RPC — that was my main concern on #371 and this resolves it cleanly. Discharging the open test-plan boxYour checklist has "maintainer confirm matrix still matches live fleet before merge" unchecked. Re-ran it just now, 2026-09-09 17:46 UTC, 5 samples per method per host: Every row in your table matches. No drift since #371 was filed. I also verified the "interchangeable for follow sync" claim rather than assuming it: the follow client's public-RPC surface is One thing I'd change before merge: the probe advice is unsound
I think this bakes in a recipe that can't be followed, and it's my fault for not being clearer in #371. There is no "stable
The mix reshuffles every time and neither code ever settles. A client told to wait for a stable The guidance the data actually supports is: don't branch on the code at all. Either code means "this host will not serve this method"; treat any error from a capability probe as unsupported and fail over to a host that does. Suggested replacement:
Smaller pointsquicknode is missing from the table. "rejects whole batches" reads stronger than the behaviour. Blockdaemon handles batches fine — the four-method follow batch above succeeded there. What it does is reject a batch containing a filtered method, discarding the unrelated calls beside it with a single top-level error ( The WS suffix deserves a clause here. The note now says the endpoints are interchangeable for follow sync, and sits directly above a list where blockdaemon uniquely needs Date-stamp the matrix. This is provider-side state that can change without any commit to this repo, and the unchecked box in your test plan is effectively an unbounded recurring ask on maintainers. An "observed YYYY-MM-DD" line plus the one-line repro makes it falsifiable by any reader instead: curl -s -X POST -H 'Content-Type: application/json' \
--data '{"jsonrpc":"2.0","id":1,"method":"eth_getProof","params":["0x3600000000000000000000000000000000000000",["0x0"],"latest"]}' \
https://rpc.testnet.arc.ioNit: the hunk adds two consecutive blank lines before Disclosure: I'm an external community contributor, not affiliated with Circle, with no write access to this repository. Advisory review only, not an approval — all measurements above are from my own probing of the public endpoints and should be confirmed independently. |
Address review on circlefin#373/circlefin#371: clarify follow sync is unaffected, fix probe advice (do not wait for stable -32601), add quicknode + date stamp, soften blockdaemon batch wording, note differing WS paths, and drop the extra blank line.
|
Thanks @osr21 — excellent catch on the probe advice and the follow-vs-app split. Updated the note to:
Matrix re-check appreciated — ready for another pass whenever you have a minute. |
|
Revision looks good — the probe guidance, quicknode row, date stamp, batch wording, and WebSocket clause all read correctly now. Two things before you consider this final, and the first is me correcting my own review. I got the batching claim wrongIn my last comment I wrote that "the follow client doesn't batch — the That was the wrong file. The four-method list is missing two methodsThe note now says the follow client "only needs
I verified all three follow endpoints serve The bigger one: blockdaemon cannot serve follow catch-up below ~41.86MAdding blockdaemon returns Binary-searching the cutoff gives a single sharp boundary, not sporadic gaps: So roughly the last 19.44M blocks (~112 days at 500 ms), though one measurement can't distinguish a rolling window from a fixed restore point. Why this is operationally sharp rather than cosmetic: in Suggested addition after the table:
Repro: curl -s -X POST -H 'Content-Type: application/json' \
--data '{"jsonrpc":"2.0","id":1,"method":"arc_getCertificate","params":[1000000]}' \
https://rpc.blockdaemon.testnet.arc.io
# {"jsonrpc":"2.0","id":1,"error":{"code":-32004,"message":"Certificate not found"}}Worth a maintainer's eye on whether that retention boundary is intended for a documented follow endpoint, since it may be a provider configuration issue rather than a docs issue. Either way the doc shouldn't imply the three are interchangeable for catch-up. Minor, in support of your current wording
Disclosure: I'm an external community contributor, not affiliated with Circle, with no write access to this repository. Advisory review only, not an approval — all measurements are from my own probing of the public endpoints on 2026-09-09 and should be confirmed independently. |
|
Thanks @osr21 — especially for correcting the batching path (`rpc_sync/client.rs`) and catching the incomplete method list. Updated the note to:
Ready for another pass whenever you have a minute. |
Address review on circlefin#373/circlefin#371: clarify follow sync is unaffected, fix probe advice (do not wait for stable -32601), add quicknode + date stamp, soften blockdaemon batch wording, note differing WS paths, and drop the extra blank line.
d72c8f6 to
d8cabdd
Compare
|
Re-measured today against the live fleet. The note reads correctly now — the method list matches what The certificate floor is fixed, not a rolling windowLast time I said "one measurement can't distinguish a rolling window from a fixed restore point." A second measurement 23 hours later can: The head advanced 162,611 blocks; the floor did not move by one. A rolling retention window would have carried the floor forward by the same amount. It is a fixed restore point. The boundary is also exact and reproducible, not approximate — 5 samples each side, no flapping, and the OK side returns the same Controls today, so this is not a general outage: What that means for the wordingThe note currently says blockdaemon "serves certificates only for recent history". That phrasing implies a sliding window, which has two consequences for a reader: they will assume the quoted number decays, and they will assume the doc rots. Neither is true. Concretely, a fixed floor means the certificate range widens over time as the head advances, but genesis catch-up on that host never becomes possible. The floor has a wall-clock anchor, which is more durable than a block number: So blockdaemon's certificate history begins 2026-05-12. Suggested tightening:
That also lets you drop the Minor
Everything else I can verify holds. The retention boundary being a deliberate restore point rather than a transient gap is probably still worth a maintainer's eye, since it is a documented follow endpoint that cannot serve the from-genesis path this page describes. Disclosure: I'm an external community contributor, not affiliated with Circle, with no write access to this repository. Advisory review only, not an approval. All measurements are my own probing of the public endpoints on 2026-09-09 and 2026-09-10 and should be confirmed independently before merge. |
|
Thanks @osr21 — especially for settling the fixed-floor vs rolling-window question with the second measurement. Updated the note to:
Ready for another look whenever you have a minute. |
43f96ae to
ac565f2
Compare
2 participants
Summary
--follow.endpointURLs indocs/running-an-arc-node.mdare interchangeable for follow sync, but not for application JSON-RPC method support.eth_getProof/eth_createAccessListand a note about unstable-32601vs-32014answers on some hosts.Docs-only; does not change provider gateways. Distinct from #222 / #299 (rate limits / gas caps / fallback config).
Addresses #371.
Test plan