Conversation
…-config v0.0.14
The current default sidecar (d3ecb1a0d0f76366) is built against
sei-config v0.0.13. Its BuildRegistry() doesn't include the
EVM.EnabledLegacySeiApis field added in sei-config v0.0.14, so any
SND with spec.template.spec.overrides["evm.enabled_legacy_sei_apis"]
hits "unknown override key" in the sidecar's ApplyOverrides at
sei-config/io.go:79-80 and the configure-genesis task fails.
Bumping to a2af4e1b8ed4 — built today from seictl v0.0.49 (commit
fb39223e5682) against sei-config v0.0.14. Verified empirically by
extracting the binary and grepping for the field name and registry
key path.
Empirical verification:
Old (d3ecb1a0d0f76366): /go/pkg/mod/github.com/sei-protocol/sei-config@v0.0.13
enabled_legacy_sei_apis: 0 occurrences in binary
New (a2af4e1b8ed4): /go/pkg/mod/github.com/sei-protocol/sei-config@v0.0.14
enabled_legacy_sei_apis: 3 occurrences (field name +
toml tag + registry key path)
Unblocks the harbor nightly release-test orchestrator's --override
evm.enabled_legacy_sei_apis=... line which would otherwise be rejected
by the in-pod sidecar's ApplyOverrides registry check.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Open
5 tasks
This was referenced May 8, 2026
bdchatham
added a commit
that referenced
this pull request
May 8, 2026
The controller validates the override map at intent-build time before forwarding to the sidecar. Without sei-config v0.0.14 in the controller binary, BuildRegistry() doesn't know evm.enabled_legacy_sei_apis and the validation rejects: validating config-apply: config-apply: invalid intent: [[ERROR] overrides.evm.enabled_legacy_sei_apis: unknown config field "evm.enabled_legacy_sei_apis"] The in-pod sidecar already had v0.0.14 (per #204's DefaultSidecarImage bump). The controller is the third sei-config layer that needs the bump for end-to-end override pipeline correctness. Tests pass. The go.sum churn is a go mod tidy artifact — sei-config v0.0.14 has a simpler transitive dep tree than v0.0.13. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
bdchatham
added a commit
that referenced
this pull request
May 8, 2026
* chore(deps): bump sei-config v0.0.13 to v0.0.14 The controller validates the override map at intent-build time before forwarding to the sidecar. Without sei-config v0.0.14 in the controller binary, BuildRegistry() doesn't know evm.enabled_legacy_sei_apis and the validation rejects: validating config-apply: config-apply: invalid intent: [[ERROR] overrides.evm.enabled_legacy_sei_apis: unknown config field "evm.enabled_legacy_sei_apis"] The in-pod sidecar already had v0.0.14 (per #204's DefaultSidecarImage bump). The controller is the third sei-config layer that needs the bump for end-to-end override pipeline correctness. Tests pass. The go.sum churn is a go mod tidy artifact — sei-config v0.0.14 has a simpler transitive dep tree than v0.0.13. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(planner): set MaxRetries on TaskDiscoverPeers via centralized lookup discoverPeersTask had MaxRetries=0 (Go zero value) at both planner sites, so the executor's retry branch (executor.go:189) short-circuited and called failTask on the first ExecutionFailed. The SeiNode went terminal PhaseFailed, the parent SND.status.phase computed to Failed, and any caller of `seictl nd watch --until=Ready` exited 65 immediately. Reproduced when the harbor nightly orchestrator co-applies validator + RPC fleet SNDs: discover-peers fires on the RPC fleet's first reconcile while the validator's pods aren't yet serving Tendermint RPC. The sidecar's DNSEndpointsSource.Discover returns "no reachable peers found via dnsEndpoints (1 endpoints tried)" — a plain fmt.Errorf, not wrapped in task.Terminal() — which the controller sees as ExecutionFailed. Adds discoverPeersMaxRetries=20 (~9 minutes with the executor's exponential-backoff capped at 30s/attempt). Also refactors the existing genesisConfigureMaxRetries and groupAssemblyMaxRetries sites to use the same lookup — the prior pattern of `if taskType == X { t.MaxRetries = ... }` was sprinkled across three plan-builders and would need a fourth edit per future retry-aware task. Now: one switch in taskMaxRetries, buildPlannedTask reads it, every call site gets the right MaxRetries without per-task-type knowledge. Tracking the deeper fix (cross-watch peer SeiNodes + refresh DiscoverPeersTask.Sources on retry) in #210. Without that, this PR papers over the symptom only when the snapshotted peer endpoint eventually becomes reachable; if the snapshotted peer is deleted or scaled away mid-plan, retries reuse the stale endpoint list. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- 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
1 participant
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
The current
DefaultSidecarImage(d3ecb1a0d0f76366) is built againstsei-config v0.0.13. ItsBuildRegistry()doesn't include theEVM.EnabledLegacySeiApisfield added insei-config v0.0.14, so any SND withspec.template.spec.overrides["evm.enabled_legacy_sei_apis"]hits"unknown override key"in the sidecar'sApplyOverrides(atsei-config/io.go:79-80) and theconfigure-genesistask fails.Bumping to
a2af4e1b8ed4— built today fromseictl v0.0.49(commitfb39223e5682) againstsei-config v0.0.14.Empirical verification
Extracted both binaries and inspected vendored sei-config + registered field:
Why this matters
Unblocks the harbor
nightlyrelease-test orchestrator'sseictl nd apply --override evm.enabled_legacy_sei_apis=sei_getLogs,sei_getBlockByNumber,sei_getBlockByHashline. Without this bump, the orchestrator-side seictl can write the override into the SND's overrides map (it knows the field at v0.0.14), but the in-pod sidecar can't apply it (it doesn't know the field at v0.0.13). Bumping the default sidecar aligns both ends of the override pipeline at sei-config v0.0.14.After this lands, the override will succeed end-to-end and the qa harness's ~16
sei_*tests will start running. From there: parity assertions can validatesei_getLogsmatcheseth_getLogsshape where they should agree, and the synthetic-tx coverage stays load-bearing.Tests
go build ./...— greengo test ./...— green (no test exercises the constant directly; the binary path is unchanged)Test plan
--override evm.enabled_legacy_sei_apis=...to the harbor nightly orchestrator (separate platform PR)-32601 not enabled on this node