rainix-sol-artifacts CI red since 2026-07-24: ETH_RPC_URL resolves empty (org secret/var, not a code regression)

[thedavidmeister]

Symptom

Rainix CI → rainix-sol-artifacts has failed on every push to main since the merge of #279 (commit 1086e28, 2026-07-24T11:59:59Z), and continues to fail on every commit since (06fa7b6, 8583c77, ...). Each run retries the deploy 10 times over ~40s before giving up with:

Error: Internal transport error: Connection refused (os error 111) with /home/runner/work/rainix/rainix/test/fixture/

That path looks like a missing local fixture/mock-RPC service, but it isn't one — see root cause below.

Root cause

.github/workflows/test.yml runs the job with:

env:
  ETH_RPC_URL: ${{ secrets.CI_DEPLOY_SEPOLIA_RPC_URL || vars.CI_DEPLOY_SEPOLIA_RPC_URL }}

and rainix-sol-artifacts (in flake.nix) invokes forge script ... --rpc-url "${ETH_RPC_URL}".

ETH_RPC_URL is resolving to an empty string. Confirmed directly from the job's own env dump, printed before any retry logic runs, identically in all three failing runs:

• job 89475572223 (run 30091492683, commit 1086e28): ETH_RPC_URL: (blank)
• job 89482744436 (run 30093743505, commit 06fa7b6): ETH_RPC_URL: (blank)
• job 89492033946 (run 30096584996, commit 8583c77): ETH_RPC_URL: (blank)

With --rpc-url '', forge can't parse it as a URL and falls back to treating it as a local path — the job's cwd (test/fixture/, set via defaults.run.working-directory) — then fails to connect to that "endpoint." Hence the misleading "connection refused ... test/fixture/" text: there is no fixture server involved, and nothing under test/fixture/ changed or broke.

Why this isn't a code regression

• .github/workflows/test.yml is byte-identical between the last known-good run and every failing run since (git diff 409759f..8583c77 -- .github/workflows/test.yml is empty).
• The last successful rainix-sol-artifacts run was 2026-07-16 (run 29506458832, job 87648364549): the job log shows --rpc-url *** (masked, i.e. non-empty) and SIMULATION COMPLETE.
• feat(sol-artifacts): network input, HyperEVM RPC slot, optional --legacy #279, the PR adjacent to the first failure, only touches .github/workflows/rainix-manual-sol-artifacts.yaml (a separate, manually-dispatched workflow) — it does not touch test.yml, flake.nix, or anything under test/fixture/.
• No commit between the last good run and the first bad run touches the rainix-sol-artifacts task definition, test.yml, or test/fixture/.

So the value behind secrets.CI_DEPLOY_SEPOLIA_RPC_URL / vars.CI_DEPLOY_SEPOLIA_RPC_URL flipped from present to empty for this repo, with no corresponding code change.

Where the secret/var actually lives

Checked what's configured directly on rainlanguage/rainix:

• Repo-level Actions secrets: gh api repos/rainlanguage/rainix/actions/secrets → {"total_count":0,"secrets":[]}
• Repo-level Actions variables: gh variable list → empty
• Repo environments: gh api repos/rainlanguage/rainix/environments → {"total_count":0,"environments":[]}

So CI_DEPLOY_SEPOLIA_RPC_URL isn't (and can't be, right now) a repo-level secret/var or environment secret on rainix itself — it must be (or have been) an org-level secret or variable on rainlanguage, shared down to this repo, that stopped resolving here around 2026-07-24T11:59:59Z: deleted, renamed, or its "selected repositories" visibility list changed to drop rainix.

I don't have admin:org on the token available to me, so I can't list/inspect rainlanguage's org-level secrets or variables to tell which of those happened, or restore it myself. Per the task guidance I'm working under, that's a "needs a secret I can't see" situation — filing this instead of guess-pushing a fix.

Ask

Someone with org-admin access on rainlanguage should check the CI_DEPLOY_SEPOLIA_RPC_URL org secret and/or org variable: does it still exist, under that exact name, with rainix in its repository-visibility list? Restoring that should turn rainix-sol-artifacts green again with no code change.

Optional follow-up (not filed as a fix here)

Independent of the above, rainix-sol-artifacts's retry loop doesn't distinguish "empty/misconfigured RPC URL" from a transient network blip — it burns all 10 retries and produces the misleading test/fixture/-path error either way. A cheap hardening would be to fail fast with an explicit message when ETH_RPC_URL is unset/empty, rather than retrying. Happy to open that as a separate small PR if wanted — flagging here rather than doing it unprompted since it doesn't address the actual outage.