A hung check-health.sh (aztec-testnet, looping on an unresponsive reference RPC)
blocked show-status.sh's parallel 'wait' for 3.5h, hanging the whole fleet
rpc-update and holding the deploy lock. Each curl was bounded (-m 3) and the
retry loop capped (3x), but the call itself wasn't time-bounded.
- sync-status.sh: wrap each check-health.sh call in 'timeout ${HC_TIMEOUT:-30}'
(-> exit 124 + 'timeout' status on overrun).
- show-status.sh: wrap the whole per-node sync-status.sh call in
'timeout ${SYNC_TIMEOUT:-60}' so the parallel wait can never block forever.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Match the dRPC gateway's per-chain "how many blocks behind is ok" model instead of a
fixed 2s/5s timestamp tolerance:
- check-health.sh: compare the reference head vs local head by BLOCK NUMBER and classify
with the chain's dRPC lag thresholds (LAGGING_LAG/SYNCING_LAG, in blocks, from
chains.yaml). dRPC uses the two thresholds inconsistently across chains (sometimes
lagging<syncing, sometimes the reverse) so the smaller is the online boundary and the
larger the syncing/drop boundary. Defaults 2/6 when a chain has no thresholds.
- multicurl.sh: also skip responses with result:null (a lagging endpoint lacking the
requested block) so the fallback reference URLs are actually tried. Previously the first
endpoint's {"result":null} was accepted as success -> fallbacks never ran, and the null
reference hash made check-health report false "forked" (the online/forked flapping).
- sync-status.sh: resolve the lag thresholds (by drpc slug or chain id) and export
LAGGING_LAG/SYNCING_LAG.
- reference-rpc-endpoint.sh: add --lags and --block-time-ms lookups.
- reference-rpc-endpoint.json: regenerated with per-chain block_time_ms + lagging_lag +
syncing_lag (additive).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Cosmos-hub has NO EVM RPC — eth_blockNumber checks don't apply. Add a --cosmos
handler that probes the CometBFT /status method: sync_info.catching_up=false =>
online, else syncing; optional head-gap check vs the drpc reference. sync-status.sh
dispatches protocol=cosmos -> check-health.sh --cosmos. eth/starknet/aztec untouched.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- sync-status.sh: resolve protocol family from the compose x-upstreams chain
label via the registry (reference-rpc-endpoint.sh --protocol) instead of
path-substring guessing; legacy path detection kept as fallback for
composes without a resolved label. Unknown families report
'unsupported protocol: X' honestly instead of a bogus eth_chainId error.
Aztec reference lookup falls back to slug urls when rollup_version is
not in the registry.
- reference-rpc-endpoint.sh: new --chain <slug> (urls by registry key,
works for idless non-EVM entries) and --protocol <slug> modes; existing
chainid and --rollup-version lookups unchanged.
- mantle-sepolia: chainid 5001 -> 5003 (verified live: 0x138b), label and
--networkid now correct
- metis-sepolia: label resolves via registry override (drpc chains.yaml
carries wrong id 59901; live chain is 59902, verified via official RPC)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Juno returns chain ID as hex-encoded ASCII (0x534e5f5345504f4c4941)
rather than plain string (SN_SEPOLIA). Match both formats.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- sync-status.sh now detects Starknet paths and uses starknet_chainId
- Maps SN_MAIN/SN_SEPOLIA chain IDs to reference endpoints
- check-health.sh accepts --starknet flag for Starknet mode
- Uses starknet_getBlockWithTxHashes instead of eth_getBlockByNumber
- Handles decimal timestamps and block_hash field differences
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
