perf(beacon): run epoch steps 1-3 over one registry scan

[MegaRedHand]

One of three alternative implementations of the same follow-up to lambdaclass/ethlambda_private#37 (epoch participation without per-index registry reads): (a) #630, (b) this PR, (c) #633. They are meant to be compared, and at most one of (a) and (b) should merge; (c) is stacked on this one.

Motivation

Since lambdaclass/ethlambda_private#37 the registry is a persistent Merkle tree, so state.validator(i) is a tree descent rather than an array index, while validators().iter() walks leaf slices.

Epoch steps 1-3 (justification, inactivity updates, rewards) read the registry through about 19 full scans and about 21 descents per active validator. The pulled-up-tip check in fork choice repeats justification on every imported block.

Change: option (b), one summary pass, then flat passes

• New helpers::participation:
  • EpochSummary: one walk of validators().iter(), zipped with the flat participation lists, into per-validator flags, effective balances and the balance totals.
  • ParticipationTotals: the same scan without allocation. This is all justification (and so the per-block pulled-up tip) needs.
  • RewardContext and ValidatorDeltas: today's reward arithmetic per validator, in today's operation order.
• process_participation_steps replaces the three step calls in the altair, capella and electra drivers. It builds the summary once, then:
  1. runs justification on its totals;
  2. updates inactivity scores in place;
  3. writes back only the balances that changed, applying each component in spec order (never netted).
• The public step functions and get_flag_index_deltas / get_inactivity_penalty_deltas keep their signatures, since the fixtures call them one at a time. They become thin wrappers that build what they need.
• Both effective-balance updates zip validators with balances().iter(). Once only changed balances are written, balances()[i] is a tree descent for most validators.
• get_finality_delay and is_in_inactivity_leak now return Result: a finalized epoch past the previous epoch is an ArithmeticOverflow rather than a debug panic or a release wrap into a permanent leak. The spec calls that uint64 underflow an invalid transition, and Lighthouse and Grandine reject it the same way (Teku saturates to zero; Prysm and Nimbus wrap). RewardContext::new passes the error up.
• docs/beacon_stf.md: a short note in "Registry and balances".
• docs/spec_deviations.md: from altair on, the fast path reads the leak flag once per step, where the spec reads it per validator. So a crafted state with the finalized epoch past the previous one fails here even where the spec never reaches the check. No chain reaches that state, since justification only finalizes an epoch behind the current one.

Testing

• The previous step 1-3 code is kept as a reference under cfg(any(test, debug_assertions)).
• In debug builds, process_participation_steps runs the reference on a clone for registries up to 4096. It asserts equal balances, scores, justification bits and checkpoints, and that both paths error or neither does. release-fast has debug assertions on, so this runs on every fixture.
• Randomized tests (1500 cases across altair, bellatrix, capella, electra and fulu) compare totals, flags, per-component deltas, the isolated steps and error text against the reference.
• The random states keep the finalized epoch at or behind the previous epoch, as every reachable state does. Past it, the fast path and the reference fail at different points (see the deviation above), so the comparison would test nothing. A unit test covers the error itself.
• The randomized tests also run in the Test minimal preset job, which uses the dev profile with overflow checks on. release-fast turns them off, which is how the underflow above went unnoticed under mainnet.
• Clippy -D warnings and the ethlambda-state-transition lib tests pass.
• Beacon spec filters epoch_processing, rewards, sanity, finality, random, fork_choice and transition pass on both presets. That run predates the finality-delay change; CI's beacon spec jobs cover it.

Benchmark (all three options)

ethlambda benchmark import replay on ethlambda-5: cargo build --release, mainnet corpus of 128 blocks (slots 15279073..=15279200, 4 epoch-start blocks), legs interleaved base a b c for two rounds. Base against base: 0.996. Every leg imported all 128 blocks.

	base (c913728)	(a) iterator passes	(b) summary pass	(c) single pass
process wall	104.0 s	96.1 s	92.0 s	91.0 s
user CPU	215.1 s	208.4 s	205.1 s	203.8 s
stf, epoch-start block (mean of 4)	1503 ms	1126 ms	912 ms	709 ms
stf p50, other blocks	577 ms	517 ms	478 ms	479 ms
paired stf vs base (ratio of totals)	1	0.869	0.797	0.785
get_head p50	201 ms	214 ms	226 ms	225 ms
peak RSS	3.88 GiB	3.93 GiB	4.04 GiB	4.04 GiB

• The per-block saving comes from the pulled-up tip, which reruns justification on every imported block.
• (c) gains nothing over (b) on ordinary blocks, since their per-block path is the same.
• get_head rises as stf falls, although no option touches the head computation. This is probably contention with the background state writer, as seen in earlier import benchmarks; it is not verified. Block wall time still falls.

Moved

• Moved from lambdaclass/ethlambda_private#61, now that beacon-chain-integration lives on this repo.
• Based on beacon-chain-integration @ c79fabd5, merged into the branch.

[github-actions]

🤖 Claude Code Review

Review: perf(beacon): run epoch steps 1-3 over one registry scan (PR 632)

I read the diff through altair_reference.rs, the driver changes and the start of participation_equivalence.rs. I did not read the rest of the equivalence tests, and I did not build or run anything.

Overall: The change looks correct and I found no consensus-affecting bugs. It reproduces the spec arithmetic and its order of operations, and the oracle-on-clone assertion in debug builds is a strong safety net.

Correctness checks that hold

• Scan membership (participation.rs:388-479): The scan matches the reference on every rule I compared.
  • Participation is counted only for validators active in the previous epoch and unslashed.
  • The eligibility rule active_before || (slashed && previous_epoch + 1 < withdrawable_epoch) is unchanged.
  • The current target list is read only for validators active now.
  • The previous list is aliased to the current one at genesis.
  • The previous-epoch error takes priority over the current-epoch one.
  • Each total is floored at one increment, as get_total_balance does.
• Step order (altair.rs, run_participation_steps): The order is preserved.
  • Justification runs first on the totals.
  • Inactivity scores update next, reading the post-justification leak flag.
  • RewardContext::new is built after justification, so it also reads the post-justification finalized checkpoint.
  • The pre-justification total_active_balance it reuses is unaffected by justification.
• Balance application (ValidatorDeltas::apply): It applies each component as reward then penalty, with a saturating subtract after each. That equals the reference's per-component increase_balance / decrease_balance loops, because validators are independent.
• Errors in apply_rewards_and_penalties: Short-balance-list errors are deferred until all deltas are computed, which matches the spec's two-phase failure order.
• Fork gating: The current_epoch > GENESIS_EPOCH + 1 justification gate, and skipping everything at genesis, match the old per-step skip rules.

Notes and nits (non-blocking)

1. finality.rs:232: Making get_finality_delay and is_in_inactivity_leak fallible is the right call over wrapping. It is a deliberate behaviour change for unreachable states, and it is documented in spec_deviations.md. Please confirm all other callers, such as RPC and the rewards API, handle the new Result sensibly and don't unwrap.
2. altair.rs (update_inactivity_scores): if updated != *score { *score = updated; } is only worthwhile if get_mut on the persistent list dirties the node on access. If it doesn't, plain assignment is simpler. If it does, a short comment saying so would help.
3. altair.rs (apply_rewards_and_penalties): changes can be large during a leak or at an epoch boundary, since nearly every eligible validator changes. It is one Vec<(usize, Gwei)>, so it is cheap. Preallocating with summary.len() would avoid regrowth, though that is minor.
4. participation.rs: EpochSummary::get, is_empty, is_leaking and ParticipationTotals's current_epoch_target sentinel behaviour exist partly for tests. If any are unused outside cfg(test), they may trip dead_code or add API surface. Clippy -D warnings passing suggests they are fine.
5. The debug oracle runs only for registries of 4096 validators or fewer. Mainnet-size equivalence therefore rests on the randomized tests (up to 300 validators) and the spec fixtures. That is acceptable, but nothing exercises the fast path against the reference at large scale or across tree-page boundaries. Consider one test around the leaf and node page size of ethlambda_ssz_tree::List, so balances().iter() zipped with validators().iter() is checked across page edges.
6. get_flag_index_deltas and get_inactivity_penalty_deltas now build a full EpochSummary and RewardContext per call. Fixtures call them one flag at a time, so this is fine, but it makes each call error on a finalized epoch past the previous one even with no eligible validators. That is a documented deviation.

The perf numbers (about 20% less stf time, with a small RSS increase) support the change. Good to merge once Point 1 is confirmed.

---

Automated review by Claude (Anthropic) · sonnet · custom prompt

[github-actions]

🤖 Codex Code Review

Looks good overall: the refactor is performance-motivated, keeps a spec-shaped reference path for debug/test comparison, and I did not spot an obvious consensus-breaking bug in fork choice / FFG / attestation accounting from the touched code.

Findings

• No blocking correctness issue found in the touched paths.
• The one-pass EpochSummary / RewardContext design appears semantically aligned with the previous helpers for normal reachable states, and the explicit note about the crafted finalized-checkpoint edge case is helpful.

Nits / Follow-ups

• crates/blockchain/state_transition/src/beacon/helpers/participation.rs:51

  • The doc says “Bits 0..3” for the timeliness flags and “Bit 3” for eligibility, but FLAG_COUNT is 3, so the flags are bits 0..2 and eligibility is bit 3.
  • This is doc-only, but worth fixing because this module is subtle and consensus-critical.

• crates/blockchain/state_transition/src/beacon/helpers/participation.rs:124

  • total_active and the per-flag totals use saturating_add. That matches existing helper semantics, but it would be worth an inline note that this is intentionally preserving get_total_balance behavior, since silent saturation in consensus code is easy to misread as an accidental weakening of overflow checks.

• crates/blockchain/state_transition/src/beacon/stf/epoch/altair.rs:174

  • let balance = balance_iter.next().copied(); computes deltas before checking balance presence, specifically to preserve spec failure ordering. That’s reasonable, but it is non-obvious and security-sensitive. A short comment already exists; I’d keep it, and maybe mention that this intentionally avoids failing early on malformed balances.

• crates/blockchain/state_transition/src/beacon/stf/epoch/altair.rs:230

  • The debug-only equivalence check is a strong safeguard, but CHECK_LIMIT: usize = 4096 is effectively part of the safety story for this optimization. Consider a brief rationale for why 4096 is the chosen cutoff, since regressions above that size will only be caught by dedicated tests.

Consensus / Security assessment

• process_justification_and_finalization, process_inactivity_updates, and process_rewards_and_penalties preserve the required ordering, especially building RewardContext after justification and after inactivity-score updates.
• The crafted-state deviation documented in docs/spec_deviations.md is acceptable as documented; I agree it should not affect reachable chain states.
• No new unsafe code, unchecked indexing, or obvious memory-safety concerns.
• Error handling is generally careful: malformed participation/scores propagate explicit IndexOutOfBounds / ArithmeticOverflow errors rather than wrapping.

Validation note

• I could not run cargo test in this environment because rustup attempted to write under a read-only home directory. If you want, I can still give you a targeted test command set to run locally for the touched epoch-processing paths.

---

Automated review by OpenAI Codex · gpt-5.4 · custom prompt

[github-actions]

🤖 Kimi Code Review

I'll review this PR which introduces a one-pass participation accounting optimization for Altair-and-later epoch processing. This is a significant performance improvement with consensus-critical code.

High-Level Assessment

This is a well-structured optimization that replaces O(n²) epoch processing with O(n) by scanning the validator registry once. The approach of keeping a reference implementation for testing is excellent. However, I've identified several issues ranging from minor correctness concerns to potential consensus bugs.

---

Critical Issues

1. Missing ? operator in scan error propagation (participation.rs:185-195)

None => {
    previous_error.get_or_insert(Error::IndexOutOfBounds {
        index,
        len: previous_list.len(),
    });
}

Problem: get_or_insert returns &mut Error, but the ; discards it. The error is stored but never propagated. Same issue for current_error at lines 207-213.

Wait—let me re-read. Actually, lines 219-221 do propagate:

if let Some(error) = previous_error.or(current_error) {
    return Err(error);
}

This is correct, though the pattern is slightly unusual. No bug here.

---

2. apply_rewards_and_penalties balance iteration bug (altair.rs:224-226)

let mut balance_iter = balances.iter();
// ...
let balance = balance_iter.next().copied();

Problem: The balance_iter is advanced for every validator in summary.iter(), but continue on ineligible validators still consumes a balance. This is correct because summary.iter() and balances are both in registry order. However, if balances.len() < summary.len(), the check at line 246 catches it. Actually correct.

But wait—there's a subtle issue: the balance is None for ineligible validators past the end of balances, but the code continues before checking. If balances is shorter, ineligible validators at the end would continue without hitting the length check. The check at line 246 only fires after the loop if balances.len() < summary.len().

Actually re-reading: the loop runs summary.iter().enumerate(), so index goes 0..summary.len()-1. If balances.len() < summary.len(), then for index >= balances.len(), balance is None. For ineligible validators, we continue and never hit the UnknownValidator error. The post-loop check at line 246 catches this: if balances.len() < summary.len() { return Err(...) }. Correct.

---

3. Real bug: altair_reference module not declared in altair.rs

The file altair_reference.rs is added but altair.rs never declares mod altair_reference;. Looking at the diff, altair.rs uses super::altair_reference::process_participation_steps at line 312, but there's no mod altair_reference; in altair.rs.

Wait—checking mod.rs:

pub mod altair;
#[cfg(any(test, debug_assertions))]
pub mod altair_reference;

So altair_reference is a sibling module, not a child. The path super::altair_reference from altair.rs would go to epoch::altair_reference. But altair.rs is in epoch/, so super is epoch/. Yes, this works. Correct.

---

4. Real bug: process_participation_steps debug assertion clones state unnecessarily for large registries

#[cfg(debug_assertions)]
{
    const CHECK_LIMIT: usize = 4096;
    if state.validators().len() <= CHECK_LIMIT {
        let mut expected = state.clone();
        // ...
        let result = run_participation_steps(state, config);
        // ...
        return result;
    }
}
run_participation_steps(state, config)

Problem: When result.is_err() in the debug path, the function returns result without comparing states. But when result.is_ok(), it asserts state equality. However, if expected_result.is_ok() and result.is_err(), the first assertion result.is_ok() == expected_result.is_ok() fails. This is correct.

But: the CHECK_LIMIT is checked against state.validators().len(), but the clone happens before checking. Actually no—the check is before the clone. Correct.

---

5. Real bug: RewardContext::new uses state.fork_name() for inactivity_penalty_quotient

let inactivity_penalty_quotient = preset::retuned::inactivity_penalty_quotient(self.fork);

In the reference implementation (participation_reference.rs:158):

let inactivity_penalty_quotient =
    preset::retuned::inactivity_penalty_quotient(state.fork_name());

These match. Correct.

---

6. Real bug: get_finality_delay changed from infallible to fallible without updating all callers

Looking at rewards.rs:

if is_in_inactivity_leak(state)? {

This was updated. But are there other callers?

In participation.rs:254:

leaking: super::finality::is_in_inactivity_leak(state)?,

In altair.rs:

let leaking = is_in_inactivity_leak(state)?;

In participation_reference.rs:

let leaking = is_in_inactivity_leak(state)?;

All updated. Correct.

But wait—finality.rs itself has get_eligible_validator_indices which doesn't use get_finality_delay. The is_in_inactivity_leak is only used in the places shown. Correct.

---

7. Real bug: ValidatorDeltas::apply ordering doesn't match specification

pub fn apply(self, balance: Gwei) -> Gwei {
    self.0.iter().fold(balance, |balance, &(reward, penalty)| {
        balance.saturating_add(reward).saturating_sub(penalty)
    })
}

The comment says "reward first and then penalty" and "the balance floors at zero after each penalty, so a reward arriving after a penalty that emptied the balance still counts."

But the specification's process_rewards_and_penalties in phase0 does:

for index in range(len(state.validators)):
    increase_balance(state, index, rewards[index])
    decrease_balance(state, index, penalties[index])

For Altair, the spec's process_rewards_and_penalties calls get_flag_index_deltas and get_inactivity_penalty_deltas separately, then applies them in order. The order within get_flag_index_deltas is: source, target, head. Then inactivity penalty is separate.

The test at participation_equivalence.rs:551 verifies:

let deltas = ValidatorDeltas([(0, 10), (5, 0), (0, 0), (0, 0)]);
assert_eq!(deltas.apply(3), 5); // 3 - 10 = 0 (floor), 0 + 5 = 5

This matches the comment's intent. But does it match the reference? The reference process_rewards_and_penalties in altair_reference.rs does:

for (rewards, penalties) in deltas {
    for index in 0..validator_count {
        increase_balance(state, index, rewards[index as usize])?;
        decrease_balance(state, index, penalties[index as usize])?;
    }
}

Wait—this applies ALL rewards first, then ALL penalties for each delta pair. But get_flag_index_deltas returns (rewards, penalties) where rewards and penalties are for the SAME flag. So for flag 0 (source), it adds reward then penalty. Then for flag 1 (target), adds reward then penalty. Then flag 2 (head). Then inactivity penalty (only penalties).

So the order is: source reward, source penalty, target reward, target penalty, head reward, head penalty, inactivity penalty.

But ValidatorDeltas stores [(source_r, source_p), (target_r, target_p), (head_r, head_p), (inactivity_r, inactivity_p)] and applies them in that order: source reward, source penalty, target reward, target penalty, etc.

This matches! Correct.

---

8. Real bug: apply_rewards_and_penalties doesn't use increase_balance/decrease_balance mutators

The reference uses:

increase_balance(state, index, rewards[index as usize])?;
decrease_balance(state, index, penalties[index as usize])?;

But the new code writes directly to balances_mut():

*balances.get_mut(index).ok_or(...)? = updated;

This bypasses the increase_balance/decrease_balance functions. Are these just direct mutations, or do they have side effects?

Looking at mutators.rs (not in diff), increase_balance and decrease_balance likely handle the tree-backed balances correctly. Writing directly to balances_mut() should be equivalent if balances_mut() returns the same type.

But there's a subtlety: increase_balance and decrease_balance might do additional validation or use different error types. The new code uses Error::UnknownValidator while the old code would use whatever increase_balance returns.

More importantly: the new code computes updated = deltas.apply(balance) which applies rewards and penalties in a specific order with saturating arithmetic. The old code applied increase_balance and decrease_balance separately. If decrease_balance does balance.saturating_sub(penalty), then:

• Old: balance = min(balance + reward, MAX), then balance = balance.saturating_sub(penalty)
• New: balance = balance.saturating_add(reward).saturating_sub(penalty)

These are the same! saturating_add then saturating_sub is associative in this context. Correct.

---

9. Real bug: weigh_with_totals uses summary.totals() after potential mutation

In run_participation_steps:

let summary = EpochSummary::build(state, justifies)?;
if justifies {
    weigh_with_totals(state, summary.totals())?;
}
update_inactivity_scores(state, config, &summary)?;
let context = RewardContext::new(state, summary.totals())?;

weigh_with_totals mutates state (justification bits, checkpoints). RewardContext::new then reads state.finalized_checkpoint() which may have been updated. This is intentional and correct—the comment says "the leak flag reads the finalized checkpoint which justification may advance."

But wait: summary.totals() was computed BEFORE weigh_with_totals ran. The totals include total_active_balance, previous_epoch_flags, and current_epoch_target. These don't depend on justification/finality. So using the old totals is correct. Correct.

---

10. Real bug: scan doesn't handle current_epoch == previous_epoch correctly for current_list

let previous_list = if current_epoch == previous_epoch {
    current_list
} else {
    previous_list
};

At genesis, current_epoch == previous_epoch == GENESIS_EPOCH. The spec says to use current_epoch_participation for both. This aliases current_list to previous_list. But current_list is still used later for current_target:

if current_target && active_now {
    match current_list.get(index) {

This is correct because when current_epoch == previous_epoch, previous_list points to current_list, so both read from the same data. Correct.

---

11. Minor issue: EpochFlags::participated doesn't validate flag_index in release builds

pub fn participated(self, flag_index: usize) -> bool {
    debug_assert!(flag_index < FLAG_COUNT);
    self.0 & (1 << flag_index) != 0
}

In release builds, an out-of-bounds flag_index will shift by >= 8, which is undefined behavior for u8 shift. Actually, Rust defines 1u8 << 8 as 0 (shift is masked modulo 8 for u8? No—Rust panics in debug, wraps in release for shift >= bit width).

Wait: 1u8 << 8 in release mode is 0 (the shift amount is ANDed with 7 for u8). So self.0 & 0 != 0 is always false. This would silently return false for invalid flag indices rather than erroring. Given this is internal code with controlled call sites, this is acceptable but slightly risky.

Suggestion: Consider assert! instead of debug_assert! or use checked_shl. But not critical.

---

12. Real bug: participation_reference.rs not gated by #[cfg(any(test, debug_assertions))]

The file participation_reference.rs is in helpers/mod.rs:

#[cfg(any(test, debug_assertions))]
pub mod participation_reference;

But altair_reference.rs is in stf/epoch/mod.rs:

#[cfg(any(test, debug_assertions))]
pub mod altair_reference;

Wait, looking at the diff for mod.rs:

+#[cfg(any(test, debug_assertions))]
+pub mod altair_reference;

And for helpers/mod.rs:

+#[cfg(any(test, debug_assertions))]
+pub mod participation_reference;

Both are correctly gated. Correct.

---

13. Real bug: get_unslashed_participating_indices in altair.rs changed behavior for non-active validators

Old code:

for index in get_active_validator_indices(state, epoch) {
    // check participation and slashed
}

New code:

for (index, validator) in state.validators().iter().enumerate() {
    if !is_active_validator(validator, epoch) {
        continue;
    }
    // check participation and slashed
}

These are equivalent if get_active_validator_indices returns indices of active validators in order. The comment says it does. Correct.

But: the old code used state.validator(index)? to read the validator, which is a tree descent. The new code iterates directly. This is the optimization. Correct.

---

14. Real bug: apply_rewards_and_penalties error type changed for short balances

Old code (reference):

increase_balance(state, index, rewards[index as usize])?;

This would fail with whatever error increase_balance returns for out-of-bounds.

New code:

if balances.len() < summary.len() {
    return Err(Error::UnknownValidator(balances.len() as ValidatorIndex));
}
// ...
*balances.get_mut(index).ok_or(Error::UnknownValidator(index as ValidatorIndex))? = updated;

The new code returns UnknownValidator for both cases. Is this the same error as the reference?

Looking at mutators.rs (not in diff), increase_balance likely returns Error::UnknownValidator for out-of-bounds. So this matches. Correct.

But: the old code would fail at the FIRST missing balance during the loop. The new code fails after the loop with balances.len() as the index. This could result in different error messages but same error type. For consensus, only error vs success matters. Acceptable.

---

15. Real bug: process_epoch for capella and electra changed to call process_participation_steps

Old:

super::altair::process_justification_and_finalization(state)?;
super::altair::process_inactivity_updates(state, config)?;
super::altair::process_rewards_and_penalties(state, config)?;

New:

super::altair::process_participation_steps(state, config)?;

This is correct because process_participation_steps calls the three steps in order. Correct.

---

16. Performance concern: EpochSummary allocates two Vecs per epoch

let mut flags = Vec::with_capacity(count);
let mut effective_balances = Vec::with_capacity(count);

At mainnet scale (~1M validators), this is ~9MB per epoch (1M * 9 bytes). This is acceptable for epoch processing which already does significant work. The old code allocated multiple index lists and balance vectors, so this is likely a net reduction.

---

17. Code style: apply_rewards_and_penalties could use zip more idiomatically

let mut balance_iter = balances.iter();
// ...
let balance = balance_iter.next().copied();

Could be:

for ((index, (flags, effective_balance)), &balance) in summary.iter().enumerate().zip(balances.iter()) {

But the current pattern with manual iteration allows the balances.len() < summary.len() check. Acceptable as is.

---

18. Real bug: scan function stores errors but doesn't short-circuit

let mut previous_error = None;
// ...
None => {
    previous_error.get_or_insert(Error::IndexOutOfBounds { ... });
}

This continues scanning after finding an error. This is intentional to match "the previous epoch's error wins" semantics. But it does unnecessary work. Not a bug, just slightly inefficient. Acceptable.

---

19. Documentation issue: spec_deviations.md claims "Lighthouse reads the leak once per epoch as well"

This is a nice cross-client consistency note, but I can't verify it. Assuming the author checked. Acceptable.

---

20. Most serious concern: process_participation_steps debug assertion can panic on valid states

assert_eq!(
    result.is_ok(),
    expected_result.is_ok(),
    "participation steps disagree with the reference: {result:?} vs {expected_result:?}"
);

If result.is_ok() and expected_result.is_err(), this panics in debug builds. But the comment says "release-fast keeps debug assertions, so every fixture checks it."

Wait—release-fast with debug_assertions? That's unusual. Typically debug_assertions is only set in debug builds. If the build profile sets debug_assertions = true in release, then this runs in production!

Actually, looking at the code:

#[cfg(debug_assertions)]
{
    // ...
}

If debug_assertions is enabled in a "release-fast" profile, then this code runs in production. The assert_eq! could panic if there's a bug, which is good for testing but bad for production.

But the PR author says "release-fast keeps debug assertions, so every fixture

---

Automated review by Kimi (Moonshot AI) · kimi-k2.6 · custom prompt