Skip to content

chore(platform): bump DefaultSidecarImage to post-#128 GHCR image#168

Merged
bdchatham merged 1 commit intomainfrom
chore/default-sidecar-bump-f3ed129
May 4, 2026
Merged

chore(platform): bump DefaultSidecarImage to post-#128 GHCR image#168
bdchatham merged 1 commit intomainfrom
chore/default-sidecar-bump-f3ed129

Conversation

@bdchatham
Copy link
Copy Markdown
Collaborator

@bdchatham bdchatham commented May 4, 2026

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

  • `go build ./...` clean.
  • Tests touching the constant pass (`internal/task/...`, `internal/noderesource/...`).
  • After merge → GHA builds new controller image → standard "chore: bump controller image" sync follows.

🤖 Generated with Claude Code

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>
@bdchatham bdchatham merged commit 0989172 into main May 4, 2026
2 checks passed
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant