test(cast): cover read commands across networks - #16472
Conversation
The read commands are what every other workflow is built on, and each of them decodes a chain's responses through Foundry's network types. Nothing covered them off Ethereum, so a chain serving a shape those types do not model breaks the command for that whole chain rather than for one transaction, and nothing in the suite notices. Each test pins the chain id, decodes a recent block with and without full transaction bodies, then cross-checks a transaction against its receipt and reads account state at the block it landed in. `block --full` is the assertion that matters on Arbitrum and Robinhood, whose every block opens with an internal transaction the strict Ethereum envelope cannot decode. The tests are `flaky_`-prefixed so the default nextest profile skips them and the nightly flaky job runs them with retries, matching the `cast run` network tests. An unreachable endpoint skips with the reason printed; a response that will not decode fails, so the case being guarded cannot quietly pass as a skip.
✅ Changelog exemptA maintainer marked this pull request as not requiring a changelog entry. |
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
Two success paths currently let this matrix pass without exercising the commands it is meant to guard. find_transaction conflates block-command/JSON failures with decoded empty blocks, while choosing only tx.to skips every account read for contract creations. The latter happens on Tempo at this revision. In addition, the successful-return skip messages are captured by the nightly nextest invocation, so the job cannot distinguish these partial runs from full coverage.
I ran all eight tests at 84919ada; they passed, but Tempo only revealed that its account checks were skipped when rerun with --success-output final. With the workflow's actual output settings it reported a plain pass. Please propagate scan/decode failures, use an account that exists for every transaction, and make any remaining deliberate skips visible in the nightly log.
`find_transaction` treated a block that would not decode the same as a block that decoded and held nothing, so a chain whose blocks cast cannot read skipped the transaction, receipt and account commands and reported a pass. It now returns `Result<Option<_>>`: a block or transaction array that will not decode is an error, and `Ok(None)` means every block decoded and none held a transaction. Selecting the account from `to` skipped all four account commands for a contract creation, which is what Tempo picks at this revision. The sender is present either way, so use it and drop the skip. Keep the output of these tests on success in the flaky profile. The nightly job does not pass `--success-output`, so nextest hid the skip diagnostics and an outage looked identical to a fully exercised network.
…hain-coverage # Conflicts: # .config/nextest.toml
3 participants
Nothing covered
cast block,cast tx,cast receiptor the account read commands off Ethereum. Each of them decodes a chain's responses through Foundry's network types, so a chain serving a shape those types do not model breaks the command for that whole chain rather than for one transaction. #16451, #16457 and #16459 were all that shape, and none of them were caught by a test.Eight networks: Ethereum, Base, Polygon, BSC, Arbitrum, Robinhood Chain, Monad and Tempo. Each test pins the chain id so an endpoint quietly repointed elsewhere fails rather than passing, decodes a recent block with and then without full transaction bodies, cross-checks a transaction against its receipt, and reads balance, nonce, code and storage at the block the transaction landed in.
block --fullis the assertion that carries the weight on Arbitrum and Robinhood, whose every block opens with a Nitro internal transaction (0x6a) that the strict Ethereum envelope cannot decode.The transaction and the receipt decode through separate paths, so agreeing on the block number is a real cross-check rather than a restatement. Blocks are searched backwards from a few confirmations behind the tip, because Tempo produces long runs of empty blocks and the sub-second chains produce plenty of their own.
Every test is
flaky_-prefixed, so the default nextest profile skips them and the nightly flaky job runs them with retries, matching thecast runnetwork tests in #16463. An unreachable endpoint skips with the reason printed while a response that will not decode fails, so the case being guarded cannot quietly pass as a skip. Both paths are verified: pointing a test at a bogus host skips, and giving it the wrong chain id fails.Endpoints are hardcoded in the test module rather than added to
foundry-test-utils, which keeps this independent of #16464 where the same chains are being added torpc.rsfor the anvil fork tests.This overlaps nothing in #16463, which replays transactions with
cast runon a partly overlapping set of chains; the command surface here is disjoint.Two things worth flagging separately from the tests.
cast tx --rawpanics rather than erroring on any Nitro system transaction, so it crashes on Arbitrum and Robinhood, where every block has one.crates/cast/src/lib.rs:1256callsencoded_2718()on the alloy transaction directly and alloy panics for a type it does not model; the--lanebranch on the next line has the same problem. This is the cast-side analogue of what #16465 fixes for anvil'sdebug_getRawTransaction, but that PR does not touch this call site.--rawis deliberately left out of the matrix here rather than encoding the crash as expected behaviour, and should join it once fixed. Tracked in #16483.Monad's system account holds more than 1e28 wei, so balances there do not fit a
u64. Worth knowing for anything that parsescast balanceoutput.This is test-only, so it needs the
L-ignorelabel rather than a changelog entry.