StakeSquid/ethereum-rpc-docker
1
0
Fork 0
Code Issues Pull Requests 15 Packages Projects Releases Wiki Activity

zero-gravity: resolve release tag by probing known forms; fail loudly on 404 #61

Manually merged
claude merged 1 commits from fix-zerog-release-tag-resolution into main 2026-08-11 06:23:54 +00:00
Conversation 0 Commits 1 Files Changed 1 +39 -4
claude commented 2026-08-11 06:22:10 +00:00
Collaborator
Copy Link

ASSET-only change (zero-gravity/zerog.Dockerfile). No gitlink bump, no source change, no regeneration — the gitlink stays deploy-owned.

Problem 1 — the release tag cannot be hardcoded

0G publishes aristotle and galileo from two different repositories, and neither uses a consistent tag format. The asset filename is always <spec>-v<version>.tar.gz; only the tag varies. Probed live 2026-08-11:

chain repo version actual tag
aristotle 0gchain-Aristotle 1.0.4 1.0.4
aristotle 0gchain-Aristotle 1.0.6 v1.0.6
galileo 0gchain-NG 3.0.3 v3.0.3
galileo 0gchain-NG 3.0.7 galileo-v3.0.7
galileo 0gchain-NG 3.0.8 v3.0.8

The old Dockerfile hardcoded download/${VER}/ for aristotle and download/v${VER}/ for galileo. Consequences:

  • aristotle could not be bumped past 1.0.4 — which matters now, because aristotle v1.0.6 carries a double-sign slashing fork (2026-06-26) that we are not on.
  • galileo could not reach 3.0.7 at all.

Fixed by resolving the tag: try the known forms in order, take the first that yields the asset.

Problem 2 — 404s failed silently, four layers later

curl -sL has no --fail, so a 404 HTML body was written into the .tar.gz and the build died at the next layer with:

tar: not in gzip format

An error that points nowhere near the cause. This has now caused three separate misdiagnoses:

  1. the de-32 build blocker, when node_version: 3.0.3 was inherited by aristotle (3.0.3 exists in 0gchain-NG, not in 0gchain-Aristotle) — fixed by pinning 1.0.4 in vibe-node f3f7f23;
  2. vibe-node PR #3087, which proposed aristotle 1.0.6 and would have reintroduced it;
  3. vibe-node PR #3189, which proposed unifying both networks onto 0gchain-NG.

Now curl -fsSL, plus an explicit guard that names the version, the repo, and every tag tried.

Verification

Resolver logic run verbatim against the real GitHub artifacts:

--- versions that must work ---
  ✅ aristotle 1.0.4  -> resolved via tag '1.0.4'
  ✅ aristotle 1.0.6  -> resolved via tag 'v1.0.6'
  ✅ galileo   3.0.3  -> resolved via tag 'v3.0.3'
  ✅ galileo   3.0.7  -> resolved via tag 'galileo-v3.0.7'
  ✅ galileo   3.0.8  -> resolved via tag 'v3.0.8'
--- must fail loudly (regression guard) ---
  ❌ aristotle 3.0.3  -> FATAL: no asset 'aristotle-v3.0.3.tar.gz' in 0gfoundation/0gchain-Aristotle under any of: 3.0.3 v3.0.3 aristotle-v3.0.3
  ❌ galileo   9.9.9  -> FATAL: no asset 'galileo-v9.9.9.tar.gz' in 0gfoundation/0gchain-NG under any of: v9.9.9 galileo-v9.9.9 9.9.9

aristotle 3.0.3 is the exact input that caused the original blocker — it now fails in seconds with an actionable message instead of an opaque tar error.

Then end-to-end against the real 68 MB aristotle-v1.0.6.tar.gz (the previously-unreachable case), including the extraction step:

0g: trying tag '1.0.6' -> .../download/1.0.6/aristotle-v1.0.6.tar.gz
curl: (22) The requested URL returned error: 404
0g: trying tag 'v1.0.6' -> .../download/v1.0.6/aristotle-v1.0.6.tar.gz
0g: resolved aristotle 1.0.6 from tag 'v1.0.6'
  ✅ aristotle-v1.0.6/ present   (tarball layout unchanged)
  ✅ bin/0gchaind (76M)
  ✅ bin/geth (46M)

The extraction branch and the chmod targets were checked explicitly, since the 1.0.6 layout had never been exercised.

⚠️ Not built as a container image — no docker daemon on the controller. The download/extract path is verified against the real artifacts; the surrounding layers are unchanged from what already builds today.

Behaviour for current pins

Unchanged. aristotle 1.0.4 still resolves on the first candidate and galileo 3.0.3 on the first — no extra requests, no behaviour change, for anything pinned today.

Follow-up this unblocks

  • aristotle → 1.0.6 (the slashing fork) becomes a pure context.yml bump in vibe-node. Land this first — bumping the version before this Dockerfile is deployed would break the build.
  • vibe-node #2912 (galileo → 3.0.8 + restore chainid: 16602) is independent of this and unaffected.

Context: closed vibe-node #2865/#2967/#3086/#3087/#3145/#3171/#3189 during the 0g cluster triage; full evidence in vibe-node #2865.

🤖 Generated with Claude Code

**ASSET-only change** (`zero-gravity/zerog.Dockerfile`). No gitlink bump, no source change, no regeneration — the gitlink stays deploy-owned. ## Problem 1 — the release tag cannot be hardcoded 0G publishes aristotle and galileo from **two different repositories**, and neither uses a consistent tag format. The asset filename is always `<spec>-v<version>.tar.gz`; only the **tag** varies. Probed live 2026-08-11: | chain | repo | version | actual tag | |---|---|---|---| | aristotle | `0gchain-Aristotle` | 1.0.4 | `1.0.4` | | aristotle | `0gchain-Aristotle` | 1.0.6 | **`v1.0.6`** | | galileo | `0gchain-NG` | 3.0.3 | `v3.0.3` | | galileo | `0gchain-NG` | 3.0.7 | **`galileo-v3.0.7`** | | galileo | `0gchain-NG` | 3.0.8 | `v3.0.8` | The old Dockerfile hardcoded `download/${VER}/` for aristotle and `download/v${VER}/` for galileo. Consequences: - **aristotle could not be bumped past 1.0.4** — which matters now, because aristotle v1.0.6 carries a double-sign **slashing fork** (2026-06-26) that we are not on. - **galileo could not reach 3.0.7** at all. Fixed by resolving the tag: try the known forms in order, take the first that yields the asset. ## Problem 2 — 404s failed silently, four layers later `curl -sL` has no `--fail`, so a 404 HTML body was written into the `.tar.gz` and the build died at the *next* layer with: ``` tar: not in gzip format ``` An error that points nowhere near the cause. **This has now caused three separate misdiagnoses:** 1. the de-32 build blocker, when `node_version: 3.0.3` was inherited by aristotle (3.0.3 exists in `0gchain-NG`, not in `0gchain-Aristotle`) — fixed by pinning 1.0.4 in vibe-node f3f7f23; 2. vibe-node PR #3087, which proposed aristotle `1.0.6` and would have reintroduced it; 3. vibe-node PR #3189, which proposed unifying both networks onto `0gchain-NG`. Now `curl -fsSL`, plus an explicit guard that names the version, the repo, and every tag tried. ## Verification Resolver logic run verbatim against the **real** GitHub artifacts: ``` --- versions that must work --- ✅ aristotle 1.0.4 -> resolved via tag '1.0.4' ✅ aristotle 1.0.6 -> resolved via tag 'v1.0.6' ✅ galileo 3.0.3 -> resolved via tag 'v3.0.3' ✅ galileo 3.0.7 -> resolved via tag 'galileo-v3.0.7' ✅ galileo 3.0.8 -> resolved via tag 'v3.0.8' --- must fail loudly (regression guard) --- ❌ aristotle 3.0.3 -> FATAL: no asset 'aristotle-v3.0.3.tar.gz' in 0gfoundation/0gchain-Aristotle under any of: 3.0.3 v3.0.3 aristotle-v3.0.3 ❌ galileo 9.9.9 -> FATAL: no asset 'galileo-v9.9.9.tar.gz' in 0gfoundation/0gchain-NG under any of: v9.9.9 galileo-v9.9.9 9.9.9 ``` `aristotle 3.0.3` is the exact input that caused the original blocker — it now fails in seconds with an actionable message instead of an opaque tar error. Then end-to-end against the real 68 MB `aristotle-v1.0.6.tar.gz` (the previously-unreachable case), including the extraction step: ``` 0g: trying tag '1.0.6' -> .../download/1.0.6/aristotle-v1.0.6.tar.gz curl: (22) The requested URL returned error: 404 0g: trying tag 'v1.0.6' -> .../download/v1.0.6/aristotle-v1.0.6.tar.gz 0g: resolved aristotle 1.0.6 from tag 'v1.0.6' ✅ aristotle-v1.0.6/ present (tarball layout unchanged) ✅ bin/0gchaind (76M) ✅ bin/geth (46M) ``` The extraction branch and the `chmod` targets were checked explicitly, since the 1.0.6 layout had never been exercised. ⚠️ **Not built as a container image** — no docker daemon on the controller. The download/extract path is verified against the real artifacts; the surrounding layers are unchanged from what already builds today. ## Behaviour for current pins Unchanged. `aristotle 1.0.4` still resolves on the **first** candidate and `galileo 3.0.3` on the first — no extra requests, no behaviour change, for anything pinned today. ## Follow-up this unblocks - **aristotle → 1.0.6** (the slashing fork) becomes a pure `context.yml` bump in vibe-node. Land this first — bumping the version before this Dockerfile is deployed would break the build. - vibe-node **#2912** (galileo → 3.0.8 + restore `chainid: 16602`) is independent of this and unaffected. Context: closed vibe-node #2865/#2967/#3086/#3087/#3145/#3171/#3189 during the 0g cluster triage; full evidence in vibe-node #2865. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude added 1 commit 2026-08-11 06:22:11 +00:00
zero-gravity: resolve release tag by probing known forms; fail loudly on 404 cfac32736e 
0G publishes aristotle and galileo from two different repos, and neither uses a
consistent release-tag format. The asset filename is always <spec>-v<version>.tar.gz;
only the tag varies:

  aristotle -> 0gchain-Aristotle   1.0.4 = "1.0.4"    1.0.6 = "v1.0.6"
  galileo   -> 0gchain-NG          3.0.3 = "v3.0.3"   3.0.7 = "galileo-v3.0.7"   3.0.8 = "v3.0.8"

The hardcoded formats meant aristotle could not go past 1.0.4 and galileo could not
reach 3.0.7. Resolve the tag by trying the known forms in order instead.

Also switch curl -sL to -fsSL. Without -f a 404 HTML body was written into the
.tar.gz and the build failed several layers later at 'tar: not in gzip format',
an error pointing nowhere near the cause. That has now caused three separate
misdiagnoses, including a de-32 build blocker.

Verified end-to-end against the real artifacts: aristotle 1.0.4/1.0.6 and galileo
3.0.3/3.0.7/3.0.8 all resolve; aristotle 3.0.3 and galileo 9.9.9 fail immediately
with an actionable message.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
claude manually merged commit cfac32736e into main 2026-08-11 06:23:54 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude cursor rob sebastian
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: StakeSquid/ethereum-rpc-docker#61
Delete Branch "fix-zerog-release-tag-resolution"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?