chore(platform): bump DefaultSidecarImage to post-#128 GHCR image#168
Merged
chore(platform): bump DefaultSidecarImage to post-#128 GHCR image#168
Conversation
Pulls in seictl#128 (metadata.db file-vs-directory dispatch fix). The old default image hardcoded addFileToTar for /sei/data/snapshots/metadata.db, which fails when metadata.db is a LevelDB directory (the actual cosmos-sdk layout). The new image (f3ed1297...) dispatches on info.IsDir(). - ghcr.io/sei-protocol/seictl@sha256:97f9f988... (pre-#128, broken on directory metadata.db) + ghcr.io/sei-protocol/seictl@sha256:f3ed1297... (post-#128, multi-arch) Effect: SNDs that don't pin spec.template.spec.sidecar.image now inherit the fixed sidecar. Existing pinned references (e.g., the protocol manifests in the platform repo) need their own bumps and are tracked separately. Verified end-to-end: pacific-1/syncer-0-0-0 was patched onto this image and a manually-fired snapshot-upload task completed without the "is a directory" failure. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
bdchatham
added a commit
that referenced
this pull request
May 7, 2026
) Previous DefaultSidecarImage (sha256:f3ed1297..., set in PR #168) predates seictl PR #143 which bumped to sei-config v0.0.13. As a result the rendered /sei/config/app.toml on archive nodes has no [receipt-store] section — seid uses the upstream default keep-recent=100000 and prunes historical receipts on first boot. This makes BYOV archive nodes with pre-populated receipt data (e.g. pacific-1-archive-0) effectively unusable: the data on disk is fine, but seid prunes it within minutes of starting. Bump to a6e00256... — the current ghcr.io/sei-protocol/seictl:latest multi-arch index — built from seictl main which has sei-config v0.0.13 ([receipt-store] archive-mode override) and the most recent seictl client features through v0.0.48. Pinning by digest (not :latest) keeps deploys deterministic. Note: a separate chain-id rendering issue surfaced during the pacific-1-archive-0 attempt — config.toml is missing chain-id entirely, causing seid to panic on genesis/config mismatch. This bump may or may not address that; chain-id rendering needs to be investigated in sei-config legacy.go regardless. After this lands: build new controller image, bump controller image tag in platform repo so the running controller picks up the new DefaultSidecarImage. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps `internal/platform/platform.go:DefaultSidecarImage` to pull in seictl#128 (the metadata.db file-vs-directory dispatch fix).
```
```
Why
The old default image hardcoded `addFileToTar` for `/sei/data/snapshots/metadata.db`, which fails with `is a directory` when metadata.db is a LevelDB directory (the actual cosmos-sdk layout). The new image dispatches on `info.IsDir()` and falls back to `addFileToTar` only for the file case.
Verified end-to-end
Pacific-1/syncer-0-0-0 was patched onto the new sidecar image and a manually-fired `snapshot-upload` task ran. Logs showed the file streaming through without the "is a directory" failure that bricked the prior attempt at the metadata.db tar entry.
Effect on consumers
SNDs that don't pin `spec.template.spec.sidecar.image` will inherit this image once the controller rebuilds. SNDs with explicit pins (e.g., the protocol manifests in the platform repo, or the fork-test) get their own bumps tracked separately.
Test plan
🤖 Generated with Claude Code