Repository navigation
Backport release/v6.7: Log a pinned node's skipped migration kick-off once per batch size - #4411
Conversation
…4408) `app/abci.go` calls `rootmulti.Store.SetMigrationBatchSize` with `NumKeysToMigratePerBlock` on every block. On a node pinned to `memiavl_only` (a memIAVL reserve), each call with a positive batch size logs the "skipping migration kick-off" ERROR, so once governance raises the rate a reserve logs it every block for the rest of its life: about 8.2k lines an hour per arctic-1 reserve pod. That buries anything else at ERROR and makes the line useless as a signal. The skip is now logged once per batch size. `Store` remembers the batch size it last logged a skip for, logs again only when governance changes the value, and forgets it when the rate goes back to 0, so raising it again logs again. A restart logs once on the first block. The same applies to the INFO line for an SC store that does not expose a configured write mode. Nothing else changes: the kick-off decision and the write mode are untouched, so this is not app-hash-breaking. Covered by `TestRootMultiAutoKickoff_FixedMemiavlOnlySkipLoggedOncePerBatchSize`, which counts log records across repeated, changed and reset batch sizes; the existing rootmulti tests pass. (cherry picked from commit 6e2c783)
PR SummaryCursor Bugbot is generating a summary for commit 1ed6686. Configure here. |
PR SummaryLow Risk Overview
Adds Reviewed by Cursor Bugbot for commit 2a0d094. Bugbot is set up for automated code reviews on this repo. Configure here. |
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
There was a problem hiding this comment.
This is a clean backport of #4408. It adds a per-batch-size log dedup to SetMigrationBatchSize, so a pinned or unknown-mode node logs the skipped migration kick-off once per batch size instead of on every block, and a batch size of 0 resets the dedup. The field is only touched from BeginBlock, which runs on one goroutine, so no race is introduced. The new test swaps the package logger without t.Parallel, and it checks repeat, change and reset-after-0 cases.
Findings: 0 blocking | 0 non-blocking | 0 posted inline
Blockers
- None at the file/PR level.
Non-blocking
- None at the file/PR level.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## release/v6.7 #4411 +/- ##
================================================
- Coverage 61.40% 60.36% -1.04%
================================================
Files 2163 2064 -99
Lines 189115 177381 -11734
================================================
- Hits 116121 107082 -9039
+ Misses 62261 60513 -1748
+ Partials 10733 9786 -947
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
The skipped-migration log now fires once per batch size instead of on every block, and the change touches only logging. Approved with no findings. Its only caller is BeginBlock, on the consensus goroutine, so the new unguarded field has no concurrent access. No consensus or state behaviour changes, the counter resets when the batch size drops to 0, and the test covers both paths. The one other reading (codex) found nothing, which matches this review, so it adds nothing here.
seidroid review · decision approve · session 8a056eada1ae441cbf40675f0868395b · turn resp_claude_63e5cf605a443f4cefd4264577a31b58 · item 3f44da5f3d285291a9e3e7734444f558
Findings: 0 blocking | 0 non-blocking | 0 posted inline
Adds the `release/v6.7` entries merged since the rc2 changelog (#4293), in prep to cut **v6.7.0-rc4**. The rc3 update (#4335) was closed without merging, so its entries are included here: - [#4411](#4411) — Log a pinned node's skipped migration kick-off once per batch size - [#4410](#4410) — Apply compiled KV repair files at a fixed height and generate them from digest inspect lists - [#4409](#4409) — feat: add migration pause handler - [#4397](#4397) — fix(evmrpc): release eth_getLogs DB-read slots when a block read panics - [#4378](#4378) — Raise goreleaser timeout to 2h - [#4377](#4377) — Fix FlatKV state sync bad-hash scenario - [#4371](#4371) — fix(seidb): keep writes in the old DB until the migration boundary first moves - [#4348](#4348) — fix(seidb): report only the current migration boundary on the snapshot gauge - [#4347](#4347) — fix(flatkv): keep 10 old checkpoints instead of mirroring memIAVL's count - [#4339](#4339) — rc3 version bump - [#4334](#4334) — Fail dynamic-gas precompile out-of-gas as an EVM out-of-gas call - [#4315](#4315) — Pin the Go builder image per architecture in build-static.sh - [#4313](#4313) — fix(memiavl): hold a snapshot reference for an iterator's lifetime - [#4295](#4295) — rc2 version bump - [#4294](#4294) — rc2 changelog backport Also returns `## v6.7` to the format used through v6.6: the version heading, `sei-chain`, and the generated PR list. The hand-written `### Improvements` and `### Upgrade guide` sections are removed; every PR they described is already a line in the generated list. Regenerated with `./scripts/generate-changelog.sh release/v6.6 release/v6.7`; only the `## v6.7` section changes. Docs-only; no code change. **Backport note:** the #4347 backport added its own line to the top of the `## v6.7` list on `release/v6.7`, and `main` doesn't have it, so the `backport release/v6.7` cherry-pick of this PR conflicts at that one spot (simulated with `git merge-tree`). Resolve it by taking this PR's side: its fifteen lines already include #4347. --------- Co-authored-by: Cursor <cursoragent@cursor.com>
## Summary - Bump `version.json` from `v6.7.0-rc3` to `v6.7.0-rc4` to cut the fourth `v6.7` release candidate. Contents since rc3: #4411, #4410, #4409, #4397, #4378, #4377, #4371, plus the rc4 changelog update (#4415, with the conflict-marker fix #4416). The changelog has already landed, so the `v6.7.0-rc4` tag will include it. - All seven are labeled `non-app-hash-breaking`. #4371 changes the AppHash only for nodes pinned to a `migrate_*` write mode while the migration hasn't started (see #4369), and the hard-fork handlers added by #4409 and #4410 are not registered for any chain in this release. Unlike rc3, moving from rc3 to rc4 should not need a coordinated validator switch. - Push `v6.7.0-rc4` by hand on this PR's merge commit once it has merged; the tagging ruleset stops `uci-release-publish` from creating it. The rc3 tag was pushed before #4339 merged and sits on `0d56aaeef`, where `version.json` still reads `v6.7.0-rc2`. - #4378 raises GoReleaser's timeout to 2h. The rc3 tag push hit the 1h limit during the emulated arm64 build and attached nothing, so rc4 is the first `v6.7` release candidate that should get binaries. ## Test plan - [x] `git diff --check` Made with [Cursor](https://cursor.com) Co-authored-by: Cursor <cursoragent@cursor.com>
…d mainnet (#4460) <!-- CURSOR_AGENT_PR_BODY_BEGIN --> The memIAVL reserve node guide on this branch builds from `v6.7.0-rc3-memiavl-reserve` and only covers testnet. `v6.7.0` is now tagged with its own reserve branch, `v6.7.0-memiavl-reserve` (`2bff7d5a9`, the same reserve patch rebased onto the final tag), and mainnet operators need a version of the guide for `pacific-1`. `docs/migration/memiavl_reserve_node.md` now builds from `v6.7.0-memiavl-reserve` and picks up what changed in the release since rc3. The pinned-mode kick-off error is logged once per batch size (#4411) instead of on every block. The composite digest uses `--memiavl-open-mode changelog` (#4419), which reads the same rows as replay. The expected `build_tags` line now matches what GNU Make 4.x prints. The guide also notes that `atlantic-2` may still report `v6.7.0-rc4`, which executes blocks the same way as `v6.7.0`. The new `docs/migration/memiavl_reserve_node_mainnet.md` mirrors it for `pacific-1`, which is still on `v6.6.3` with no upgrade plan. A reserve prepared now runs the normal `v6.6` binary and switches to the reserve build at the `v6.7` upgrade height. The parameter query answers `migration: unknown subspace` until then, and a reserve state-synced after the upgrade must restore a snapshot from after it. Docs only. The part to scrutinise is the mainnet sequencing. The reserve build swallows `ErrUpgradeBeforeTrigger`, so starting it on `pacific-1` before the `v6.7` height, or restoring an older snapshot, quietly executes `v6.6` blocks with `v6.7` code. Before a plan exists it logs nothing at all. The guide covers this in step 3, Upgrades, Don't, and Troubleshooting. I checked the guides by building `seid` and `seidb` from `2bff7d5a9`, running `seid init` for both chain IDs, and triggering each startup-guard message on a throwaway home. I also ran the parameter and upgrade-plan queries read-only against public `pacific-1` and `atlantic-2` RPCs. The `docker build` line was checked against the Dockerfile but not run. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-daf67652-24ca-529a-ae0f-97dcd75b7099?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-daf67652-24ca-529a-ae0f-97dcd75b7099&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: alexander-sei <alexander-sei@users.noreply.github.com>
Backport of #4408 to
release/v6.7.