Repository navigation
query: name the real count and cap in the --max-sh-creates refusal - #1037
Conversation
The unpaged scripthash join refusal was the fixed string
'scripthash join exceeds --max-sh-creates (default 10000)' whatever cap
was configured, so a node at --max-sh-creates=100000 still told clients
the cap was 10000.
StoreError::ShCreatesCap { creates, cap } replaces the fixed
Query::MAX_SH_CREATES_MSG, which is deleted. Display keeps the prefix:
'scripthash join exceeds --max-sh-creates (14437 creates, cap 10000)'.
Esplora maps it to 503 explicitly; the catch-all would make it 500.
sh_history_caps failed on master with the old message (cap 2). The
query and Esplora journeys now assert the exact count and cap; removing
the Esplora arm fails esplora_sh_join_and_template on the 503.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Summary
The change replaces the fixed --max-sh-creates refusal string with StoreError::ShCreatesCap { creates, cap }, whose Display names the count that was compared and the cap that was in force, and deletes Query::MAX_SH_CREATES_MSG. That is the right shape: Rejected only carries a 'static str, so the numbers cannot live there, and the new variant is produced only from the unpaged sh_join_limited gate (query / Electrum / Esplora), not from block ingest. Esplora maps it to 503 with that Display text; without the arm the existing catch-all would have returned 500. Electrum already surfaces QueryError via to_string() (JSON-RPC code 1), IBD still drops a peer only for Rejected(UNDECODABLE_WIRE_MSG), and ConfirmRejectClass does not see this error. Display-test indices match the vector order, scripthash_create_count is already u32, and in-tree callers of the removed const are updated. No correctness issues.
Issue counts by severity
- bugs: 0
- suggestions: 0
- nits: 0
The refusal for an unpaged scripthash join over
--max-sh-createswas a fixedstring,
scripthash join exceeds --max-sh-creates (default 10000), whatevercap was configured. On a node running
--max-sh-creates=100000(and during ameasurement at
1000000) every refusal still told Electrum and Esploraclients the cap was 10000, and said nothing about how far over the request was.
StoreError::ShCreatesCap { creates, cap }replaces the fixedQuery::MAX_SH_CREATES_MSG(deleted, one path). Display keeps the same prefix,so callers that match on it still do:
Esplora maps the new variant to 503 explicitly. Without that arm the catch-all
would have turned this refusal into a 500.
Tests (red first:
sh_history_capsfailed on master with the old messagewhile the cap was 2):
rbitcoin-querysh_history_caps: chain stats, history and the filteredslot path now assert the exact message,
(7 creates, cap 2).rbitcoin-esploraesplora_sh_journey: still 503, now with(3 creates, cap 2)in the body.rbitcoin-storedisplay_and_source_arms: the new arm's Display.rbitcoin-electrumjourney unchanged (asserts the prefix).Docs:
docs/operator/storage.mdshows the new message. Changelog fragmentchangelog.d/sh-cap-message.md.Local CI except coverage, all green on rustc 1.95.0 (devShell):
cargo fmt --check,cargo clippy --workspace --all-targets -D warnings,cargo deny check(cargo-deny 0.19.6 from nixpkgs; CI pins 0.20.2),./scripts/ast-grep.sh,cargo test --workspace --quiet(2837 passed, 0 failed),./scripts/ci-os-smoke.sh.Refs #1036 (the cap's cost on a mainnet node).
🤖 Generated with Claude Code