Repository navigation
77 specs claimed the probe was non-cacheable by design. It is not. - #2894
Merged
Merged
Conversation
Every RPC spec carried some version of: "Non-cacheable by design: the rotating id defeats edge caches that would answer a bare head query without touching a node." Measured 2026-10-08 against the keyed endpoints from the probe containers: sending the SAME call with a FIXED id instead of a rotating one changes latency by 2% on Chainstack and 4% on QuickNode. The id is in nobody's cache key. That is what JSON-RPC 2.0 implies and we should have read it that way: `id` is a client correlation token with no semantic meaning, so any cache that parses the request normalises it away and keys on method plus params. Rotating it defeats a naive body-hash cache and nothing else. The claim has been on the site since the probe moved off eth_blockNumber. The replacement does not swap one unverified claim for another. It says what the probe does, says plainly that it does not guarantee a cache miss, and cites the measurement: "The request id rotates, but that does not guarantee a cache miss: many caches normalise `id` away. Measured 2026-10-08, fixed and rotating ids answer within 2 to 4 percent of each other." 77 files, six wording variants including a bare "Non-cacheable by design." on xrp-rpc. The first pass of this edit pushed 76 methodology bullets past the 500-character cap, so the replacement was shortened; `pnpm validate` passes on 246 specs and no bullet is over the cap. This came out of a QuickNode challenge to the keyed numbers. They were right to push. The caching question is now answered (it is not caching), but the separate finding that three of four keyed providers are published 4 to 6x slower than they answer is still open and is being traced in #2892.
Flotapponnier
added a commit
that referenced
this pull request
Oct 8, 2026
…builds (#2895) #2892 put this on dev. The probe services deploy from the GitHub repo with no branch pinned, so they build main; the instrumentation was never compiled and four deploys produced an identical image. Nine minutes spent waiting for a log line that could not exist, and a binary whose mtime never moved off 16:35 was the clue I should have read sooner. The diagnostic itself is unchanged and off by default (PROBE_TRACE_CONN=1). What it answers: three of the four keyed providers are published 4 to 6x slower than they answer a direct, pooled, 25-sample measurement taken from inside the probe container, while GetBlock's published number matches its measured one. The residual is about 25 ms, which is the cost of a TLS handshake from these containers. Logging Reused and WasIdle per call settles whether that is connection reuse, and therefore whether the keyed cohort's published ranking is wrong on nine pages. Caching and the rotating id were ruled out separately and the false non-cacheable claim is already corrected in #2894. 65 insertions, zero deletions. go build and go vet clean.
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.
77 specs claimed the probe was non-cacheable by design. It is not.
Every RPC spec carried some version of:
"Non-cacheable by design: the rotating id defeats edge caches that would
answer a bare head query without touching a node."
Measured 2026-10-08 against the keyed endpoints from the probe containers:
sending the SAME call with a FIXED id instead of a rotating one changes
latency by 2% on Chainstack and 4% on QuickNode. The id is in nobody's cache
key.
That is what JSON-RPC 2.0 implies and we should have read it that way:
idisa client correlation token with no semantic meaning, so any cache that parses
the request normalises it away and keys on method plus params. Rotating it
defeats a naive body-hash cache and nothing else. The claim has been on the
site since the probe moved off eth_blockNumber.
The replacement does not swap one unverified claim for another. It says what
the probe does, says plainly that it does not guarantee a cache miss, and
cites the measurement:
"The request id rotates, but that does not guarantee a cache miss: many
caches normalise
idaway. Measured 2026-10-08, fixed and rotating idsanswer within 2 to 4 percent of each other."
77 files, six wording variants including a bare "Non-cacheable by design." on
xrp-rpc. The first pass of this edit pushed 76 methodology bullets past the
500-character cap, so the replacement was shortened;
pnpm validatepasses on246 specs and no bullet is over the cap.
This came out of a QuickNode challenge to the keyed numbers. They were right
to push. The caching question is now answered (it is not caching), but the
separate finding that three of four keyed providers are published 4 to 6x
slower than they answer is still open and is being traced in #2892.