iotaledger / iota / 28211780407

67%

Build Type

push

github

Committed by web-flow

Commit Message

fix(starfish): process commit observer recovery in bounded batches (#12037)

# Description of change

During recovery, the commit observer's
`recover_linearizer_and_solidifier_state` scanned the entire
`recovery_start..=last_commit_index` range into a single
`Vec<TrustedCommit>` and accumulated one `PendingSubDag` per commit
before seeding the commit solidifier. When the unprocessed range is
large (e.g. transaction data lagged behind commits for a long period so
commits stay unprocessed), the whole range was materialized in memory at
once at startup.

This processes the range in bounded batches, mirroring
`resend_unprocessed_solid_commits`: each batch scans one chunk, rebuilds
linearizer state for commits in the `gc_depth * 2` window, seeds the
solidifier, and finalizes solid sub-dags. The solidifier cursor is set
once before the loop; disjoint, ascending, contiguous batches feed the
solidifier exactly as a single pass would, so the recovered
linearizer/solidifier state and the set and order of sub-dags sent to
the consumer are unchanged — only peak memory during recovery is reduced
(the transient scan and the per-batch pending buffer become `O(batch)`
instead of `O(range)`).

The batch size is a `commit_recovery_batch_size` local parameter
(default 250; 3 under the simulator), shared by both recovery phases.
`Parameters::validate` rejects a zero value, which would otherwise panic
`step_by(0)`.

The commit solidifier's internal pending-sub-dag buffer still holds the
unprocessed range while the front of that range is missing transactions;
that is inherent to seeding (identical to the previous single-pass
behaviour) and is a separate, tail-side concern.

## Links to any relevant issues

Fixes #12036

## How the change has been tested

- [x] Basic tests (linting, compilation, formatting, unit/integration
tests)
- [x] Patch-specific tests (correctness, functionality coverage)
- [x] I have added tests that prove my fix is effective or that my
feature works... (continued)

Coverage Stats

70 of 71 new or added lines in 3 files covered. (98.59%)

869 existing lines in 28 files now uncovered.

158805 of 235145 relevant lines covered (67.53%)

470278.7 hits per line