test: batch DIP0008 activation with slow_mode=False - #7501
Conversation
|
✅ Final review complete — no blockers (commit 52b2e58) |
Wire the existing slow_mode parameter through to activate_by_name and use batch-50 on both DIP0008 activation paths. activate_by_name already syncs after every batch and disables SPORK_17, so batch-50 matches the former batch-10 behavior without the post-reorg catch-up risk that once justified slow_mode=True.
3bb0a3a to
52b2e58
Compare
Changed-test CI timing comparisonTest: Develop baseline:
The changed test was faster in all five applicable CI configurations, saving 1m 05s across them in this pair of runs. These are the functional test runner's per-test durations from the CI logs, not whole-job or whole-suite runtimes. The changed test passed in every applicable configuration. The PR's overall SQLite job failure occurred elsewhere and does not affect these test timings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 52b2e58e82
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| n.invalidateblock(oldhash) | ||
| self.sync_all() | ||
| # Smaller batches keep the replacement chain synchronized on slow CI builds after invalidateblock. | ||
| first_quorum = self.test_dip8_quorum_merkle_root_activation(False, True) |
There was a problem hiding this comment.
Use fast batch mode on the second activation
When the post-invalidateblock activation runs, this True argument flows through to activate_by_name, where slow_mode=True selects batches of 10 rather than 50. Consequently, this path retains the previous batching behavior despite the change description stating that both DIP0008 activation paths use slow_mode=False; only the first call is accelerated. Pass False or omit the second argument to apply the intended optimization to both paths.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Intentional for the post-invalidateblock path — smaller batches keep the replacement chain synchronized on slow CI. PR description updated accordingly.
WalkthroughThe DIP8 coinbase merkle roots functional test now passes its existing Estimated code review effort: 1 (Trivial) | ~3 minutes 🚥 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/functional/feature_dip4_coinbasemerkleroots.py`:
- Around line 122-123: Update the first_quorum call to
test_dip8_quorum_merkle_root_activation so its second argument is False,
matching the fast activation mode used by the other DIP8 path and preserving the
intended batch size.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5b611186-3d72-444b-bd5c-72aa60921251
📒 Files selected for processing (1)
test/functional/feature_dip4_coinbasemerkleroots.py
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Codex + Sonnet
This one-commit PR wires the previously-dead slow_mode parameter through to activate_by_name, letting the first (pre-reorg) DIP0008 activation use 50-block batches instead of the old default of 10. The second (post-invalidateblock) activation explicitly keeps slow_mode=True with a new comment justifying it, which is a sound and safe choice, but it directly contradicts the commit message's claim of using batch-50 "on both DIP0008 activation paths." That's a real, verifiable inconsistency between the stated rationale and the actual diff, though it has no functional or test-safety impact.
Review provenance
- Codex reviewers:
gpt-5.6-sol— general (completed),gpt-5.6-sol— dash-core-commit-history (completed) - Verifier:
claude-sonnet-5— final-verifier - Sonnet reviewers:
claude-sonnet-5— general (completed),claude-sonnet-5— dash-core-commit-history (completed)
🟡 1 suggestion(s)
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `test/functional/feature_dip4_coinbasemerkleroots.py`:
- [SUGGESTION] test/functional/feature_dip4_coinbasemerkleroots.py:122-123: Commit message claims batch-50 on both activation paths, but the second path still passes slow_mode=True
The commit message says this change makes both DIP0008 activation call sites use batch-50, but the code tells a different story: `test_dip8_quorum_merkle_root_activation(False, True)` explicitly passes `slow_mode=True`, which `activate_by_name` maps to `batch_size = 10` (see test_framework.py:1571). Only the first call at line 118 (which relies on the new `slow_mode=False` default) actually gets batch-50; the second, post-`invalidateblock` call intentionally keeps the old slow batching, as the added comment on line 122 explains. Keeping slow mode here is a reasonable and probably correct choice for CI stability after a reorg, but the commit message overstates the change ("use batch-50 on both DIP0008 activation paths") in a way that could mislead anyone reading history later. Update the commit message/PR description to say batch-50 now applies to the first (pre-reorg) activation only, while the post-reorg path intentionally remains slow.
| # Smaller batches keep the replacement chain synchronized on slow CI builds after invalidateblock. | ||
| first_quorum = self.test_dip8_quorum_merkle_root_activation(False, True) |
There was a problem hiding this comment.
🟡 Suggestion: Commit message claims batch-50 on both activation paths, but the second path still passes slow_mode=True
The commit message says this change makes both DIP0008 activation call sites use batch-50, but the code tells a different story: test_dip8_quorum_merkle_root_activation(False, True) explicitly passes slow_mode=True, which activate_by_name maps to batch_size = 10 (see test_framework.py:1571). Only the first call at line 118 (which relies on the new slow_mode=False default) actually gets batch-50; the second, post-invalidateblock call intentionally keeps the old slow batching, as the added comment on line 122 explains. Keeping slow mode here is a reasonable and probably correct choice for CI stability after a reorg, but the commit message overstates the change ("use batch-50 on both DIP0008 activation paths") in a way that could mislead anyone reading history later. Update the commit message/PR description to say batch-50 now applies to the first (pre-reorg) activation only, while the post-reorg path intentionally remains slow.
source: ['codex']
|
CI note: #7501 only touches |
Issue being fixed or feature implemented
feature_dip4_coinbasemerkleroots.pyactivates DIP0008 with the defaultslow_mode=Truepath, which mines activation blocks in batches of 10. That is slower than necessary on the first activation path:activate_by_namealready disables SPORK_17 for the whole activation window and syncs after every batch.What was done?
Pass the existing
slow_modeparameter through toactivate_by_nameand useslow_mode=False(batch size 50) on the first DIP0008 activation path.The post-
invalidateblockactivation intentionally keepsslow_mode=True. Smaller batches keep the replacement chain synchronized on slow CI builds after invalidateblock.Coverage is preserved:
DIP0008_HEIGHT).sync_blocks().How Has This Been Tested?
python3 -m py_compile test/functional/feature_dip4_coinbasemerkleroots.pygit diff --check upstream/develop...HEADdashdbuild (develop tip2e52d33fa3b), alternating baseline and candidate with unique datadirs and port seeds; all runs passedupstream/developMedian improvement: 33.810 seconds (27.4%).
Breaking Changes
None.
Checklist: