main goes red on RPC weather: 37 forks, no retry, and the fork/chain split does not hold

[thedavidmeister]

main is red right now, and was red at 8d1e5fd, from a provider returning HTTP error 500 … "Temporary internal error. Please retry" on vm.createSelectFork. Nothing about the repo changed. This recurs — #26's own PR body records base_sepolia answering 408 Request timeout on the free plan, PR #19's CI failed on two chain tests for the same reason, PR #20's on five.

A repo whose default branch reds on provider weather is a repo where red stops meaning anything.

Three things combine to cause it

1. The fork surface is large. 37 createSelectFork calls across three test files on main:

file	calls
test/src/lib/LibRainDeploy.t.sol	31
test/src/abstract/RainDeployVerifyChain.t.sol	5
test/src/abstract/RainDeployVerifyChainCandidate.t.sol	1

2. The fork-free/chain split does not hold where it matters. #26 separated chain-anchored assertions into *Chain* contracts so an unreachable endpoint fails only those, and CLAUDE.md documents forge test --no-match-contract Chain as forking nothing. But LibRainDeployTest is not a Chain contract and holds 31 of the 37 forks — so that documented selection forks 31 times, and an outage fails it. The split is real for the verification abstracts and absent for the library's own suite.

3. Nothing retries. There is no retry or fallback around any createSelectFork in the repo. One transient 500 fails the job.

Many of those forks buy nothing

Some tests fork and then replace everything they touch with vm.etch, reading no chain state at all. testDeployZoltuFailedCallReportsZeroAddress (test/src/lib/LibRainDeploy.t.sol:399) forks Arbitrum, then etches the factory and deploys type(MockDeployable).creationCode — nothing in it depends on the fork. RainDeployVerifyBase.deriveDeployment proves the point by running deployZoltu on a bare local EVM.

testDeployZoltuRevertsWhenFactoryCallFailsWithAddressData (:1133) is a second instance and is also fully subsumed by the test at :399 — same fork, same etch, same call, but asserting only the revert selector where :399 asserts the exact payload. It can be deleted outright.

These are examples, not the list. The category is: a test that etches everything it reads does not need a fork.

Ask

1. Audit all 37. Delete the fork from every test that reads no chain state; delete :1133 entirely.
2. Whatever genuinely needs a chain moves into a *Chain* contract, so --no-match-contract Chain forks nothing, as CLAUDE.md already claims.
3. Decide whether the remaining chain tests get a retry around createSelectFork. Shared CI concern — if the answer is yes, it likely belongs in rainix rather than here.

Ordering matters: (1) and (2) shrink the surface (3) has to cover.

[thedavidmeister]

Closing. The red this was filed about is fixed, and not by anything in this repo.

Cause: RAINIX_RPC_SECRET_BASE_SEPOLIA (org secret RPC_URL_BASE_SEPOLIA_FORK) held a free-tier endpoint. rainix's rpc-preflight rejected it with rpc error 30 — the same code as the {"message":"Request timeout on the free plan, please upgrade to paid plan","code":30} body that killed the fork suites — then fell back to a public default that survived three sample probes and 408'd once a real fork started pulling accounts. The other four networks were on healthy paid secrets throughout.

Fix: the secret was replaced with a paid archive endpoint. Preflight now reads:

base_sepolia: SELECTED secret[0] (chain 84532, archive at block 38000000, 3/3 samples)

No rejection, no fallback, rpc-preflight: clean. That is the reason to believe it rather than the green run count.

Against the three things the title names:

1. 37 forks — still 37. Only a problem when endpoints are unreliable, which was the actual fault.
2. No retry — still true. Nothing retries vm.createSelectFork. That belongs in rainix's preflight or a createSelectFork wrapper, not here, so it is not left open against this repo. Worth filing against rainix if it bites again; there is currently no evidence it will.
3. The fork/chain split does not hold — resolved by removal. docs: drop the --no-match-contract Chain selection nobody runs #38 deleted the forge test --no-match-contract Chain claim from CLAUDE.md and two other sites, because nothing invokes that command — no CI step, no script, no flake package — and CI runs forge test -vvv over the whole suite.

#34 attempted point 3 by splitting the tests instead, and was closed unmerged: it served a command with no caller, and would not have fixed the red regardless, since CI runs everything.