build: bump kwil-db to keep block apply fast on long chains - #1438
Conversation
Time Submission Status
Submit or update total time with: Add time on top of previous submission with: See available commands to help comply with our Guidelines. |
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe ChangesKwil dependency update
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other Merge Risk: ⚪ Minimal · up to The dependency update preserves the node-visible block-store behavior on supported paths; no specific merge-blocking behavior change was identified. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 1 system. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@holdex pr submit-time 30m |
Part of:
The node pins
kwil-dbateb765df9, which v2.6.0 shipped. One commit has landed on kwil-db main since then, and this moves the pin to it,a206f35b:Why it matters
A node keeps one index entry in memory for every block it has stored. Testnet is at 12.56 million blocks, so on its leader the index was 85% of a heap already above
GOMEMLIMIT. Collection ran back to back, 94% of the leader's CPU went to it, and blocks waited for a CPU 40% of the time they spent executing and committing. That is why the testnet sentry caught up at 5.8 blocks per second on v2.6.0, with the network taking 14 seconds of the 7 hours 39 minutes.v2.6.0 rebuilt with only this change ran on the testnet sentry for 45 minutes:
Mainnet nodes have more memory headroom and 2.77 million blocks, so they are not in this state today. Without this change they would get there as the chain grows.
Consensus
Nothing that executes or hashes a block changes. The change is to how the block store holds its index in memory.
Best()returns the same height, hashes and time stamp as before, and it has a test for that, including after the index is rebuilt at startup.kwil-db/corehas no changes in this range; its pin moves with the module.Verification
a206f35bis identical to the one that ran on the testnet sentry above (git diffbetween them is empty).go build ./...andgo vet -tags kwiltest ./...are clean, with Go 1.25.3 as the Dockerfile uses.kwild's startup opens, so I did not rerun the schema suites for this bump.go.moddiff is the twokwil-dblines;go mod tidychanged nothing else.There is no Problem issue for this in node. It delivers work merged under the kwil-db Goal above, so it carries no closing keyword.
Summary by CodeRabbit