fix(ci): declare ethereum and hyperevm rpc endpoints by thedavidmeister · Pull Request #5 · rainlanguage/rain.math.float.deploy

thedavidmeister · 2026-08-21T18:38:09Z

The failure

Every Manual sol artifacts run on this repo dies part-way through the deploy:

Error: script failed: vm.createSelectFork: invalid rpc url: ethereum

script/Deploy.sol iterates LibRainDeploy.supportedNetworks() — arbitrum,
base, base_sepolia, ethereum, flare, hyperevm, polygon. foundry.toml
declared five of those seven under [rpc_endpoints].

An undeclared alias is not a skip. vm.createSelectFork("ethereum") cannot
resolve the alias, reverts, and takes the whole script down — after it has
already broadcast to arbitrum, base and base_sepolia. The network ordering is
what makes that worst: the failure lands mid-deploy, not at startup.

Foundry never maps the alias ethereum onto ETHEREUM_RPC_URL on its own; the
[rpc_endpoints] entry is what creates that binding. So a green rpc-preflight
step cannot help here — the variable is exported and reachable and the alias
still does not resolve.

The fix

Declare all seven, in both sections:

[rpc_endpoints]: add ethereum = "${ETHEREUM_RPC_URL}" and
hyperevm = "${HYPEREVM_RPC_URL}".
[etherscan]: add matching entries, because rainix-manual-sol-artifacts
passes --verify by default — a broadcast to a chain with no [etherscan]
entry succeeds and then fails at verification.

ethereum and hyperevm carry an explicit chain = 1 / chain = 999.
Foundry does not know either string as a chain name; its own names are
mainnet and hyperliquid. With chain stated, forge config resolves the
entries to chain = "mainnet" and chain = "hyperliquid". The five existing
entries need no chain because foundry resolves those aliases unaided.

The config values are byte-identical in shape to rain.factory.deploy and
rain.extrospection.deploy.

The section comments are rewritten. The [rpc_endpoints] one described the old
five-network shape and credited the alias list to LibDecimalFloatDeployProdTest
rather than to the deploy script, which is the thing that actually forces all
seven. The [etherscan] one is a deliberate divergence from the wording in
rain.extrospection.deploy: that comment says foundry "raises a config error
for an unknown alias with neither chain nor url", and I could not reproduce
that — forge config accepts the entry with chain dropped. The replacement
states the behaviour I did reproduce. The sibling repos' values are unchanged
and still match; only this repo's prose differs, and it differs by being
checkable.

Verification

Reproduced and then re-run, both as a simulation — no --broadcast, no
--verify, nothing signed or sent — with public RPC URLs and anvil's published
default test key.

Before (unmodified main), with a working ETHEREUM_RPC_URL exported:

Error: script failed: vm.createSelectFork: invalid rpc url: ethereum

After (this branch), same environment:

Script ran successfully.
Gas used: 29586463
== Logs ==
Deploying from address: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
Deploying to network: arbitrum Block number: 25805303
Deploying to network: base ...
Deploying to network: base_sepolia ...
Deploying to network: ethereum ...
Deploying to network: flare Block number: 67936509
Deploying to network: hyperevm Block number: 43798799
Deploying to network: polygon Block number: 92421242

All seven aliases resolve; zero occurrences of invalid rpc url in the run, and
the script body reaches the same final address on every network.

The simulation then stops in foundry's post-script "Setting up 7 EVMs" phase
with error code -32000: state ... is not available — the free public endpoints
this local reproduction was pointed at are not archive nodes. That is a property
of those endpoints, not of the config; CI's rpc-preflight binds
archive-capable URLs. The claim under test is alias resolution, and alias
resolution is fixed.

What this does not fix

Manual sol artifacts still cannot complete a decimal-float deploy on all
seven networks, because the log tables at
0xc51a14251b0dcF0ae24A96b7153991378938f5F5 are not deployed on ethereum or
hyperevm and DecimalFloat's constructor asserts they are present. The
log-tables suite has to run on those two chains first. This PR is what lets
either dispatch reach them at all.

Manual sol artifacts broadcasts on chain, so it is not dispatched from here.
That stays a human decision.

QA

Discriminating tests: n/a — the change is foundry.toml config, and this
repo has no test that reads [rpc_endpoints]. The discriminator is
forge script script/Deploy.sol run as a simulation: it fails on base
(invalid rpc url: ethereum) and succeeds on this branch, in the same shell
with the same seven *_RPC_URL variables exported. Both runs captured.
Mutations applied:
- delete ethereum = "${ETHEREUM_RPC_URL}" from [rpc_endpoints] →
  Error: script failed: vm.createSelectFork: invalid rpc url: ethereum.
  KILLED.
- delete hyperevm = "${HYPEREVM_RPC_URL}" from [rpc_endpoints] →
  Error: script failed: vm.createSelectFork: invalid rpc url: hyperevm.
  KILLED.
- delete chain = 999 from [etherscan].hyperevm → forge config still
  exits 0. SURVIVED that probe. The narrower claim does hold and is what
  the comment now says: forge verify-check --chain hyperevm and
  --chain ethereum are both rejected as invalid --chain values, so neither
  alias is a chain foundry can resolve on its own, and with chain stated
  forge config reports chain = "hyperliquid" / chain = "mainnet". I
  could not construct a probe that fails without chain and passes with it
  short of a real --verify broadcast, which is not run from here.
Oracle:LibRainDeploy.supportedNetworks() in
dependencies/rain-deploy-0.1.7 is the list script/Deploy.sol iterates —
seven names, independent of foundry.toml. The required [rpc_endpoints]
set is that list, not anything derived from the config being changed.
rain.factory.deploy and rain.extrospection.deploy are an independent
second reading of the same shape.
Category check: the failure is one cause — the alias set is short of the
network set — in two sections ([rpc_endpoints] for forking,
[etherscan] for the --verify that rainix-manual-sol-artifacts passes by
default). Both covered. The log-tables gap on ethereum/hyperevm is a
deployment fact, not a config fact, and is stated above rather than fixed.

`script/Deploy.sol` iterates `LibRainDeploy.supportedNetworks()`, which is seven networks. `[rpc_endpoints]` declared five. `vm.createSelectFork` does not skip an alias it cannot resolve — it reverts with `invalid rpc url: ethereum` — so every `Manual sol artifacts` run died on the fourth network, after broadcasting to arbitrum, base and base_sepolia. Adds `ethereum` and `hyperevm` to `[rpc_endpoints]` and to `[etherscan]`, matching rain.factory.deploy and rain.extrospection.deploy. The `[etherscan]` entries carry `chain = 1` / `chain = 999` because foundry raises a config error for an alias it cannot itself resolve to a chain id. Also rewrites the two section comments, which described the old five-network shape and attributed the alias list to the prod test rather than to the deploy script.

The previous wording claimed foundry raises a config error for an alias with neither "chain" nor "url". That does not reproduce: `forge config` accepts the entry either way. What does reproduce is that foundry has no chain named `ethereum` or `hyperevm` — `forge verify-check --chain ethereum` and `--chain hyperevm` are both rejected as invalid values, the canonical names being `mainnet` and `hyperliquid`. With `chain` stated, `forge config` resolves the entries to `chain = "mainnet"` and `chain = "hyperliquid"`; the other five aliases it resolves unaided. Values are unchanged; this is the comment only.

coderabbitai · 2026-08-21T18:38:18Z

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in:23 minutes

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: e1981114-0a24-4677-bd6c-136c8a1d063c

📥 Commits

Reviewing files that changed from the base of the PR and between f724824 and 7660c31.

📒 Files selected for processing (1)

foundry.toml

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

thedavidmeister · 2026-08-21T18:51:22Z

Why the red checks here are not this PR's

This branch is main plus foundry.toml. Every red check on it is red on
main too, and each has its own PR:

rainix-sol / static and the first 31 seconds of rs-static — the
org no-ignored-tests gate, on the vm.skip at
test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol:24. Fixed by
fix(test): drop vm.skip from the tagged deploy constants check #3.
the rest of rs-static — the denofmt pre-commit hook, on CLAUDE.md
and README.md. Fixed by style(docs): deno fmt CLAUDE.md and README.md #6. Not visible from this branch, because the
no-ignored-tests gate exits before pre-commit runs.
rainix-sol / test — LibDecimalFloatDeployProdTest fails 5/5 because
DecimalFloat has no code at its Zoltu address on any chain. Not fixable by
any PR; it needs the on-chain deploy that this PR is a precondition for.

This one is deliberately not stacked on the others: it is the change that
unblocks Manual sol artifacts, and per #1 that dispatch is what unblocks the
Soldeer publish and then rain.math.float#263. It should be free to merge first.

Manual sol artifacts is not dispatched from here — it broadcasts on chain.

…nfig Both go stale on their own without anything updating them. "ethereum and hyperevm ... have no log tables yet, so the log-tables suite has to run there before decimal-float can" is a fact about today's chain state. It becomes false the moment those are deployed. The deploy ordering is recorded in the issue and the PR body, which is where it belongs. "Nothing is published yet, so the first release sets this to the version its sol-v* tag names" is false after the first publish, and the two lines above it already state the rule the version line follows. What is left in both places says what the setting does and what breaks without it, which stays true. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

baku-ccron added 2 commits August 21, 2026 18:31

This was referenced Aug 21, 2026
style(docs): deno fmt CLAUDE.md and README.md #6
Open
fix(test): drop vm.skip from the tagged deploy constants check #3
Open

thedavidmeister merged commit 6759ff7 into mainAug 21, 2026
6 of 9 checks passed

Navigation Menu

Uh oh!

fix(ci): declare ethereum and hyperevm rpc endpoints - #5

fix(ci): declare ethereum and hyperevm rpc endpoints#5
thedavidmeister merged 3 commits into
mainfrom
2026-08-21-deploy-rpc-endpoints-all-networks

thedavidmeister commented Aug 21, 2026

Uh oh!

coderabbitaiBot commented Aug 21, 2026•
edited
Loading

Review limit reached

Uh oh!

thedavidmeister commented Aug 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

thedavidmeister commented Aug 21, 2026

The failure

The fix

Verification

What this does not fix

QA

Uh oh!

coderabbitaiBot commented Aug 21, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

thedavidmeister commented Aug 21, 2026

Why the red checks here are not this PR's

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

coderabbitaiBot commented Aug 21, 2026•
edited
Loading