Bump version to 0.6.2 for all packages in the project #1457
Conversation
WalkthroughBumps package versions in many Cargo.toml files (0.6.1 → 0.6.2) and regenerates numerous autogenerated runtime weight files: updated numeric weight constants, some weight method signatures gained a trailing unused parameter, and import lines were consolidated across multiple weight modules. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 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 |
Chralt98
added
s:review-needed
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1457 +/- ##
=======================================
Coverage 93.28% 93.28%
=======================================
Files 181 181
Lines 35049 35049
=======================================
Hits 32696 32696
Misses 2353 2353
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (10)
runtime/common/src/weights/pallet_treasury.rs (1)
91-104: Minor formatting inconsistency in autogenerated code.Line 103 has inconsistent indentation (3 spaces) compared to the surrounding lines (12 spaces). While this is autogenerated code and syntactically correct, if you control the template (
frame_weight_template.hbs), consider fixing the indentation for consistency..saturating_add(T::DbWeight::get().writes(4)) .saturating_add(T::DbWeight::get().writes((2_u64).saturating_mul(p.into()))) - .saturating_add(Weight::from_parts(0, 2607).saturating_mul(p.into())) + .saturating_add(Weight::from_parts(0, 2607).saturating_mul(p.into())) }zrml/neo-swaps/src/weights.rs (1)
94-95: Minor: Inconsistent indentation in autogenerated code.The final
.saturating_add()call has 11 spaces instead of 12, slightly misaligning with the chain above. This pattern repeats across all similar weight functions (lines 120, 143, 166, 189, 212, 252, 277, 302, 330).Since this is autogenerated, the fix belongs in the template file (
./misc/weight_template.hbs) rather than this file.runtime/common/src/weights/pallet_preimage.rs (1)
244-255: Minor indentation inconsistency in auto-generated code.Line 254 has inconsistent indentation (3 spaces instead of the expected 12 spaces used elsewhere). This appears to be a template artifact, but worth noting for template maintenance.
.saturating_add(Weight::from_parts(0, 2607).saturating_mul(n.into()))The rest of the auto-generated weight recalibrations look correct.
runtime/common/src/weights/frame_system.rs (1)
131-142: Minor indentation inconsistency (template artifact).Line 141 has 3-space indentation instead of the expected 12 spaces, matching the pattern seen in other auto-generated weight files. This is a template artifact.
zrml/prediction-markets/src/weights.rs (1)
248-249: Recurring 3-space indentation inconsistency (template artifact).Multiple lines have 3-space indentation instead of 12 spaces for the
.saturating_add(Weight::from_parts(0, ...))calls. This pattern appears in lines 248, 545, 569-570, 594-595, and 773. Consider fixing the weight template (./misc/weight_template.hbs) to ensure consistent indentation.Also applies to: 545-546, 569-570, 594-595, 773-774
runtime/common/src/weights/pallet_balances.rs (2)
48-48: Unused import:RocksDbWeightThe
RocksDbWeightconstant is imported but never used in this file—all weight calculations useT::DbWeight::get()instead. This is likely a template quirk from the benchmark generator.Since this is an autogenerated file, consider updating the weight template (
./misc/frame_weight_template.hbs) to conditionally include this import only when needed, which would clean up future regenerations.
140-144: Minor indentation inconsistency on line 144.Line 144 has 11 spaces of indentation while adjacent lines (142-143) use 12 spaces. This is a minor formatting inconsistency from the template.
.saturating_add(T::DbWeight::get().reads((1_u64).saturating_mul(u.into()))) .saturating_add(T::DbWeight::get().writes((1_u64).saturating_mul(u.into()))) - .saturating_add(Weight::from_parts(0, 2607).saturating_mul(u.into())) + .saturating_add(Weight::from_parts(0, 2607).saturating_mul(u.into()))runtime/common/src/weights/pallet_bounties.rs (1)
206-210: Minor indentation inconsistency on line 210.Same template issue as in
pallet_balances.rs—line 210 has 11 spaces instead of the expected 12..saturating_add(T::DbWeight::get().writes(1)) .saturating_add(T::DbWeight::get().writes((3_u64).saturating_mul(b.into()))) - .saturating_add(Weight::from_parts(0, 5214).saturating_mul(b.into())) + .saturating_add(Weight::from_parts(0, 5214).saturating_mul(b.into()))runtime/common/src/weights/pallet_membership.rs (1)
48-48: UnusedRocksDbWeightimport.The
RocksDbWeightis imported but not used in this file - all DB weight references useT::DbWeight::get(). This is likely a template artifact from the autogeneration process and is harmless given the#![allow(unused_imports)]directive at line 46.runtime/common/src/weights/pallet_democracy.rs (1)
48-48: Unused import:RocksDbWeightThe import includes
constants::RocksDbWeightbut the implementation usesT::DbWeight::get()throughout. Since this is an autogenerated file from a template, this is a low-priority issue that should be addressed in the template (misc/frame_weight_template.hbs) rather than this file directly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
runtime/common/src/weights/frame_system.rs(3 hunks)runtime/common/src/weights/orml_currencies.rs(4 hunks)runtime/common/src/weights/orml_tokens.rs(6 hunks)runtime/common/src/weights/pallet_balances.rs(9 hunks)runtime/common/src/weights/pallet_bounties.rs(13 hunks)runtime/common/src/weights/pallet_collective.rs(9 hunks)runtime/common/src/weights/pallet_democracy.rs(27 hunks)runtime/common/src/weights/pallet_identity.rs(18 hunks)runtime/common/src/weights/pallet_membership.rs(9 hunks)runtime/common/src/weights/pallet_migrations.rs(10 hunks)runtime/common/src/weights/pallet_multisig.rs(3 hunks)runtime/common/src/weights/pallet_preimage.rs(15 hunks)runtime/common/src/weights/pallet_proxy.rs(6 hunks)runtime/common/src/weights/pallet_scheduler.rs(12 hunks)runtime/common/src/weights/pallet_timestamp.rs(3 hunks)runtime/common/src/weights/pallet_treasury.rs(9 hunks)runtime/common/src/weights/pallet_utility.rs(2 hunks)runtime/common/src/weights/pallet_vesting.rs(11 hunks)zrml/authorized/src/weights.rs(4 hunks)zrml/combinatorial-tokens/src/weights.rs(10 hunks)zrml/court/src/weights.rs(20 hunks)zrml/futarchy/src/weights.rs(5 hunks)zrml/global-disputes/src/weights.rs(9 hunks)zrml/hybrid-router/src/weights.rs(4 hunks)zrml/neo-swaps/src/weights.rs(13 hunks)zrml/orderbook/src/weights.rs(4 hunks)zrml/parimutuel/src/weights.rs(4 hunks)zrml/prediction-markets/src/weights.rs(38 hunks)zrml/styx/src/weights.rs(3 hunks)zrml/swaps/src/weights.rs(11 hunks)
🧰 Additional context used
🧬 Code graph analysis (6)
zrml/hybrid-router/src/weights.rs (3)
zrml/neo-swaps/src/weights.rs (4)
buy(54-54)buy(83-96)sell(55-55)sell(108-121)primitives/src/traits/hybrid_router_amm_api.rs (2)
buy(93-99)sell(133-139)zrml/hybrid-router/src/lib.rs (2)
buy(232-257)sell(288-313)
zrml/global-disputes/src/weights.rs (1)
zrml/global-disputes/src/lib.rs (3)
add_vote_outcome(266-311)purge_outcomes(388-430)refund_vote_fees(329-369)
runtime/common/src/weights/pallet_collective.rs (1)
zrml/court/src/weights.rs (2)
vote(59-59)vote(175-185)
zrml/swaps/src/weights.rs (2)
zrml/swaps/src/lib.rs (4)
pool_exit(123-131)open_pool(1252-1262)close_pool(1225-1235)destroy_pool(1237-1250)primitives/src/traits/swaps.rs (3)
open_pool(52-52)close_pool(46-46)destroy_pool(49-49)
runtime/common/src/weights/pallet_democracy.rs (1)
zrml/court/src/weights.rs (2)
delegate(55-55)delegate(109-123)
zrml/court/src/weights.rs (3)
runtime/common/src/weights/pallet_democracy.rs (1)
delegate(304-317)runtime/common/src/weights/pallet_collective.rs (1)
vote(153-164)runtime/common/src/weights/pallet_parachain_staking.rs (1)
set_inflation(70-78)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Summary
🔇 Additional comments (67)
zrml/parimutuel/src/weights.rs (2)
22-22: Header benchmark metadata update looks consistentDATE and benchmark metadata are updated while keeping tool version and command comments intact. For an auto-generated weights file this is expected and looks fine.
74-76: Rebenchmarked weight values are consistent with existing structureOnly the minimum execution time comments and
Weight::from_partsvalues forbuy,claim_rewards, andclaim_refundswere adjusted; proof sizes, DB reads/writes, and overall structure are unchanged. For an auto-generated weights module this is a straightforward re-baselining and looks good.Also applies to: 91-93, 108-110
zrml/styx/src/weights.rs (3)
22-22: Header metadata update looks consistent with benchmark invocationDATE and STEPS/REPEAT align with the documented
frame-omni-benchercommand (steps=50, repeat=20); treating this as a correct regeneration of the weights metadata.
69-71: cross() weight constants remain coherent with proof and DB access patternThe updated minimum execution time comment and
Weight::from_parts(46_691_000, 3513)are internally consistent with the estimated proof size (3513) and unchangedreads(2)/writes(1)adjustments, so this recalibration looks good.
80-82: set_burn_amount() weight update matches storage access patternThe new minimum execution time and
Weight::from_parts(9_240_000, 0)align with the zero proof estimate and singlewrites(1)adjustment onStyx::BurnAmount; no issues spotted with this regenerated weight.zrml/orderbook/src/weights.rs (4)
22-22: Benchmark metadata/date update is consistent and non-functionalHeader DATE change to
2025-12-03is aligned with a new benchmark run; this is documentation-only and does not affect behavior.
66-74:remove_orderweight bump aligns with new benchmark timingUpdated minimum execution time and
Weight::from_parts(48_321_000, 4714)are consistent (ref_time remains above measured min; proof size and DB reads/writes unchanged), so this looks like a correct re-benchmark.
85-93:fill_orderweight adjustments are internally consistentNew min exec time and
Weight::from_parts(116_603_000, 6214)keep ref_time safely above the measured minimum, with unchanged proof size and DB access counts; this matches an expected recalibration only.
102-110:place_orderre-bench values look correctThe increased min execution time and
Weight::from_parts(56_912_000, 4714)maintain the usual relationship between timing and ref_time, with storage/proof metadata unchanged; no functional risk here.runtime/common/src/weights/orml_tokens.rs (6)
22-22: Benchmark DATE metadata update is consistent with an automated re-runThe new DATE line just reflects a fresh benchmark run and doesn’t affect behavior; keeping this in sync with the generation time is correct for traceability.
58-66:transferweight constants updated cleanly with unchanged DB access patternThe measured proof size, min exec time, and
Weight::from_partsvalues have been adjusted, while the documented storage accesses and the.reads(3)/.writes(3)calls remain aligned. This looks like a straightforward regenerated weight with no structural change.If you haven’t already, double‑check this file against the latest
frame-omni-bencheroutput fororml_tokens::transferto ensure no manual edits slipped in.
71-79:transfer_allweight refresh preserves correct storage accountingNumeric weight and min‑time values have changed, but the proof size constant matches the documented
Estimated: 6214, and the DB weights still correspond to the annotatedTokens::AccountsandSystem::Accountaccesses (3 reads, 3 writes). No issues spotted.Please confirm the regenerated numbers match your benchmark artifact for
transfer_allfor this release.
84-92:transfer_keep_aliveweight numbers updated with consistent proof/DB usageThe updated measured proof size and min execution time align with a new benchmark run;
Weight::from_parts(…, 6214)still matches the estimated proof size, and the.reads(3)/.writes(3)calls match the storage docs. Behavior is unchanged.It may be worth spot‑checking this extrinsic’s weight in your benchmark report since its base time shifted noticeably.
97-105:force_transferretains correct 4-read / 3-write profile with new base weightThe new measured/min‑time values and base ref_time look like a normal re‑calibration. Storage comments (2
Tokens::Accounts, 2System::Account) still match.reads(4)/.writes(3), and the proof size constant matches the estimated value.Consider validating this against the benchmark CSV/log for
force_transferas part of your usual release checklist.
112-120:set_balanceweight update correctly tracks changed proof size and timingThe measured proof size and min exec time have been bumped, and
Weight::from_parts(…, 3602)matches the documented estimated proof size. The 3-read / 3-write DB pattern is unchanged and still matches the storage annotations. Nothing problematic here.As a sanity check, verify that the
set_balanceentry in your generated weights (e.g., CSV or JSON) matches these constants.zrml/combinatorial-tokens/src/weights.rs (1)
19-254: LGTM! Autogenerated weights file properly regenerated.This file was correctly regenerated using the Substrate Benchmark CLI on 2025-12-03 as documented in the header. The changes include:
- Updated weight constants from fresh benchmark runs
- Trailing commas added to method signatures (formatting change in the generator)
- All modifications are mechanical and expected for a benchmark re-run
zrml/hybrid-router/src/weights.rs (4)
22-22: Updated benchmark metadata is fineDATE and benchmark parameters simply document the new benchmarking run and do not affect runtime behavior.
54-55: Trait signature formatting change is non-functionalThe added trailing comma in
fn buy(n: u32, o: u32, )/fn sell(...)is just formatting; the methods still take the same(n: u32, o: u32)parameters and preserve the existing API for callers.
83-101: Rebenchmarkedbuyweight looks structurally correctThe new
buy(n, o, )weight keeps the usual pattern: base execution weight plus linear terms innando, DB reads/writes matching the documented storage accesses, and proof-size contributions2612 * nand3765 * oaligned with the comment estimates. For an auto-generated file this looks consistent and safe to accept.
124-141: Rebenchmarkedsellweight is consistent with comments andbuySimilarly,
sell(n, o, )follows the same structure asbuy: updated base weight and linear multipliers fornando, DB operations matching the storage docs, and proof-size multipliers2612 * nand3724 * oin line with the estimates. No issues from a runtime/weighting perspective.runtime/common/src/weights/pallet_multisig.rs (3)
21-25: Benchmark metadata update looks consistent with a fresh runThe updated DATE and surrounding benchmark metadata align with an auto-regenerated weight file for this release. No manual changes needed here.
48-48: Import consolidation is fine for this generated moduleThe
frame_supportimports are grouped in a standard way for generated weight files. Even though not all imported items are used,#![allow(unused_imports)]is present, so this is acceptable and keeps the template uniform across pallets.
55-63: Updated multisig weights and signatures look correct for an auto-generated fileAll modified
WeightInfomethods follow the expected pattern (base cost + linear components ins/z+ DB read/write costs where applicable) and stay within safe numeric ranges. Given this is auto-generated benchmark output, there’s no sign of logic issues or inconsistencies in the updated weights or signatures.Also applies to: 68-80, 85-97, 104-116, 120-130, 134-144, 148-158
runtime/common/src/weights/pallet_treasury.rs (6)
19-49: LGTM!The header date update and import consolidation are consistent with a regenerated benchmark file. The single-line import is cleaner and functionally equivalent.
60-68: LGTM!Weight recalculation for
spend_localis consistent with benchmark regeneration.
71-79: LGTM!Weight recalculation for
remove_approvallooks correct.
109-117: LGTM!Weight recalculation for
spendis consistent with benchmark output.
122-130: LGTM!Weight recalculation for
payoutlooks correct.
133-152: LGTM!Weight recalculations for
check_statusandvoid_spendare consistent with benchmark regeneration. Both correctly share the same estimated proof size (3542) given their identical storage access pattern.zrml/authorized/src/weights.rs (1)
19-85: Autogenerated weight file looks correct.The weight recalibrations and updated benchmark date are consistent with a fresh benchmark run. The trailing comma in the
authorize_market_outcome_first_reportsignature (lines 54, 75) is valid Rust syntax and appears to be an artifact of the weight template.zrml/futarchy/src/weights.rs (1)
19-101: Autogenerated weight file looks correct.The weight recalibrations are consistent with the benchmark regeneration pattern seen across the PR. The trailing comma in
take_proposalssignature is a template artifact matching other weight files.zrml/global-disputes/src/weights.rs (3)
53-62: Autogenerated trait signatures look correct.The trailing commas in function signatures are a template artifact. The signature changes maintain backward compatibility with existing call sites.
206-221: Intentionally unused_oparameter is correct.The
_oparameter inpurge_outcomesis prefixed with underscore because the benchmark determined that whileoaffects proof size (see "Measured" comment:o * (32 ±0)), it does not significantly affect execution time. The proof size accounting viaEstimatedis handled correctly. The call site inlib.rs(line 428) correctly passesowners_lenas the second argument.
226-241: Intentionally unused_oparameter is correct.Same pattern as
purge_outcomes- the_oparameter affects proof size but not execution time per the benchmark results. The call site inlib.rs(line 366) correctly passesowners_lenas the second argument.zrml/neo-swaps/src/weights.rs (4)
53-67: Autogenerated trait signatures look correct.The trailing commas in parameter lists (e.g.,
fn buy(n: u32, )) are valid Rust syntax and typical of template-generated code from the Substrate benchmark CLI.
83-95: Weight calculations correctly structured.The weight calculation pattern is consistent: base weight from benchmark + linear scaling per
n+ database read/write costs + proof size scaling. The updated constants reflect the new benchmark run.
316-330: Unused parameter_min weight calculation.The
mparameter (range[32, 64]) is accepted but not used in the weight calculation—onlyncontributes to the weight. The underscore prefix correctly suppresses the unused variable warning.This is likely intentional if benchmarks showed
mhad negligible impact on execution time, but please verify this matches the expected behavior.
341-348: LGTM!The implementation correctly reflects the storage access pattern (
r:1 w:0) with only a.reads(1)call and no writes.runtime/common/src/weights/pallet_preimage.rs (1)
1-73: Auto-generated weight updates look correct.The trailing comma in function signatures (e.g.,
fn note_preimage(s: u32, )) is an artifact of the benchmark template and is valid Rust syntax. The recalibrated weight values and updated benchmark date (2025-12-03) are consistent with the version bump.runtime/common/src/weights/frame_system.rs (2)
87-100: Benchmark now includes Migrations::Cursor storage read.The
set_code()function now includes a read forMigrations::Cursorstorage, incrementing reads from 1 to 2. This reflects updated runtime behavior where code upgrades check the migration cursor state. The weight recalibration is appropriate.
155-168: Consistent migration cursor check in apply_authorized_upgrade.Similarly,
apply_authorized_upgrade()now includesMigrations::Cursorstorage read, incrementing reads from 2 to 3. This aligns with theset_code()changes and reflects the current runtime behavior.zrml/prediction-markets/src/weights.rs (3)
53-89: Trait signature updates with trailing commas are consistent.The
WeightInfoZeitgeisttrait method signatures have been updated with trailing commas (e.g.,fn admin_move_market_to_closed(c: u32, )). This is a template artifact and maintains API compatibility since the function parameters themselves are unchanged.
628-638: Unused parameter_nis intentional.The
schedule_early_close_after_disputefunction has parameter_nwhich is not used in the weight calculation. This is intentional - the trait requires the parameter for API consistency, but benchmarking showed this parameter doesn't significantly affect execution time for this specific function.
649-659: Same pattern: unused_nparameter in schedule_early_close_as_market_creator.Consistent with the previous function,
_nis declared but unused in the weight calculation, indicating the parameter doesn't materially affect execution time for this operation.runtime/common/src/weights/pallet_timestamp.rs (1)
56-71: LGTM - Weight recalibrations are reasonable.The updated weight values for
set()andon_finalize()show minor decreases, which is expected behavior from benchmark recalibration. The import consolidation and date update are consistent with other files in this PR.runtime/common/src/weights/orml_currencies.rs (1)
58-114: LGTM - Weight recalibrations for orml_currencies are appropriate.All weight functions show modest increases in execution time estimates, which is consistent with recalibrated benchmarks. The measured proof sizes have been updated to reflect current state sizes. No API changes, just updated benchmark data.
runtime/common/src/weights/pallet_bounties.rs (1)
51-211: Autogenerated weight updates look correct.The benchmark regeneration with updated execution times and weight calculations is consistent with the PR's version bump objective.
runtime/common/src/weights/pallet_utility.rs (1)
51-97: Autogenerated weight updates are consistent.Weight recalibrations across
batch,as_derivative,batch_all,dispatch_as, andforce_batchreflect updated benchmark data. The slight increases in base weights (e.g., ~10% for batch operations) are within normal variance for hardware/runtime differences.runtime/common/src/weights/pallet_migrations.rs (2)
184-196: Improved weight accuracy forclear_historic.The function now correctly includes:
- Parametric reads/writes scaling with
n- Proof size contribution scaling with
n(line 195)This is a correctness improvement from the updated benchmarks.
Note: Line 195 has the same minor indentation inconsistency (11 vs 12 spaces) as other files—a template quirk.
69-76: DB read now correctly included inprogress_mbms_none.The updated benchmark now explicitly accounts for the storage read of
Migrations::Cursor(line 75), improving weight accuracy.runtime/common/src/weights/pallet_proxy.rs (1)
51-216: Autogenerated weight updates are consistent.All weight function recalibrations for pallet_proxy reflect the updated benchmark data from 2025-12-03. The function signatures, DB weight contributions, and parametric scaling are all properly preserved.
runtime/common/src/weights/pallet_collective.rs (1)
1-296: Autogenerated weight updates look consistent.This file contains autogenerated benchmark weights for
pallet_collective. The changes include:
- Updated benchmark date (2025-12-03)
- Consolidated imports
- Trailing comma formatting in function signatures (consistent with the template pattern)
- Updated weight constants from fresh benchmark runs
The weight values and patterns are consistent with Substrate's frame-omni-bencher output.
runtime/common/src/weights/pallet_membership.rs (1)
1-198: Autogenerated weight updates are consistent.The benchmark weight updates for
pallet_membershipfollow the same pattern as other weight files in this PR:
- Updated benchmark metadata
- Trailing comma parameter formatting
- Recalibrated weight constants
All changes align with the autogeneration template output.
runtime/common/src/weights/pallet_identity.rs (1)
1-416: Autogenerated weight updates are consistent.The
pallet_identityweight file has been regenerated with updated benchmarks. All changes follow the expected autogeneration patterns:
- Fresh benchmark date and recalibrated weight constants
- Trailing comma formatting in function signatures
- Consistent use of
T::DbWeight::get()for storage cost accountingThe weight functions cover the full identity pallet API surface and the values appear reasonable for the measured operations.
runtime/common/src/weights/pallet_vesting.rs (3)
106-113: Unused parameters invest_other_lockedare intentional benchmark artifacts.The
_land_sparameters are prefixed with underscores because the benchmark results showed these parameters don't significantly affect the weight for this operation. The weight is computed as a flat base cost without per-parameter scaling. This is valid autogenerated output.
148-157: Parameter_lunused invested_transferweight calculation.Similar to
vest_other_locked, thelparameter (number of locks) doesn't contribute to the weight scaling forvested_transfer, whiles(number of vesting schedules) does. This reflects the actual benchmark measurements.
1-251: Autogenerated vesting weight updates are consistent.All weight functions for
pallet_vestinghave been regenerated with updated benchmark values. The patterns follow the standard autogeneration template, including proper handling of parameters that don't contribute to weight scaling.runtime/common/src/weights/pallet_scheduler.rs (1)
1-274: Autogenerated scheduler weight updates are consistent.The
pallet_schedulerweight file has been regenerated with updated benchmark values. Notable observations:
- Large measured sizes (92KB+) for
set_retry,set_retry_named,cancel_retry, andcancel_retry_namedare expected, as these operations work with full scheduler agendas- All weight functions follow the standard autogeneration patterns
- The trailing comma formatting and import consolidation are consistent with other weight files in this PR
runtime/common/src/weights/pallet_democracy.rs (3)
62-70: LGTM - Updated weight constantsThe weight function implementations follow the standard Substrate benchmarking pattern with updated execution times and proof sizes from the new benchmarks.
256-268: Trailing comma in parameter list is consistent with codebase patternThe trailing comma syntax
fn on_initialize_base(r: u32, ) -> Weightis valid Rust and matches the pattern used in other weight files (e.g.,zrml/court/src/weights.rsline 54:fn delegate(j: u32, d: u32, ) -> Weight). This is a style choice in the benchmark template.The minor indentation inconsistency on line 267 (11 spaces instead of 12) originates from the benchmark template and is purely cosmetic.
304-317: LGTM - Delegation weight function properly scales with referendum countThe weight correctly accounts for the linear scaling based on the number of referendums
r, with appropriate reads/writes proportional tor. The formula structure matches the expected pattern for operations that iterate over referendums.zrml/court/src/weights.rs (3)
19-43: LGTM - Autogenerated file updated with fresh benchmarks.This file was regenerated on 2025-12-03 with updated benchmark results. As an autogenerated weight file, the changes (updated date, weight values, and method signatures) are expected for a version bump.
76-513: Weight implementations updated correctly.All weight function implementations have been updated consistently:
- Method signatures match the trait with trailing commas
- Benchmark results (execution times, proof sizes, standard errors) have been refreshed
- DB read/write operations are preserved
- Unused parameters are properly marked with underscore prefix
The generated weight calculations follow the expected pattern and structure.
53-74: Trailing comma pattern in method signatures is automatically generated and valid.The trailing commas in parameterized methods (e.g.,
fn join_court(j: u32, )) are correctly applied across the trait definition and all implementations. This pattern is consistent across all 12 pallet implementations (court, swaps, styx, prediction-markets, orderbook, parimutuel, global-disputes, hybrid-router, neo-swaps, futarchy, authorized, combinatorial-tokens), indicating it's part of an automated code generation process. The implementations match their trait signatures exactly, and there are no compilation issues.zrml/swaps/src/weights.rs (3)
79-92: Autogenerated weight calculations look correct.The implementation correctly parameterizes weight by asset count
a, applying per-item multipliers for both execution time and proof size. The pattern of reads/writes scaling with2 * aaligns with theTokens::Accountsstorage access pattern documented in the comments.
101-207: Updated benchmark values for fixed-asset operations look reasonable.The weight values for single-asset operations (
pool_exit_with_exact_*,pool_join_with_exact_*,swap_exact_*) reflect updated benchmark data without structural changes. Read/write counts remain consistent with the documented storage proofs.
53-65: All trait implementors and call sites are properly updated for the new parameter signatures.The
WeightInfoZeitgeisttrait modifications inzrml/swaps/src/weights.rsare correctly implemented. Each module defines its ownWeightInfoZeitgeisttrait for its specific operations (not a shared trait), so there are no cross-module compatibility concerns. All five modified methods (pool_exit,pool_join,open_pool,close_pool,destroy_pool) are called correctly inzrml/swaps/src/lib.rswith the asset count parameter passed as expected.
What does it do?
Bump version to 0.6.2 for all packages in the project
What important points should reviewers know?
transaction_versionandspec_versionhave already been upgraded in a previous commit for this release.Is there something left for follow-up PRs?
What alternative implementations were considered?
Are there relevant PRs or issues?
References
Summary by CodeRabbit
Chores
Performance / Fees
✏️ Tip: You can customize this high-level summary in your review settings.