Skip to content

fix(#265): bound prune_expired_parameter_proposals per-call work - #326

Open
Stickernote145 wants to merge 1 commit into
hartz0:mainfrom
Stickernote145:fix/265-prune-expired-proposals-bounded
Open

Stickernote145 wants to merge 1 commit into
hartz0:mainfrom
Stickernote145:fix/265-prune-expired-proposals-bounded

Conversation

@Stickernote145

@Stickernote145 Stickernote145 commented Oct 24, 2026 •

Copy link
Copy Markdown

Summary

closes #265.
closes #262
closes #263
closes #264

prune_expired_parameter_proposals iterated the entire pending-proposals vector in a single unbounded loop. If a long period elapsed without pruning and dozens of proposals accumulated, executing this function inside one propose_parameter_change transaction could exhaust the Soroban resource budget and abort the transaction.

Changes

storage.rs

  • Added prune_expired_parameter_proposals_bounded(env, max_prune) -> u32: iterates the pending IDs vector but breaks as soon as max_prune expired proposals have been marked and removed. Returns the count pruned.
  • prune_expired_parameter_proposals now delegates to the bounded variant with MAX_PENDING_PARAMETER_PROPOSALS (10) as the cap, so the function signature and all existing callers stay unchanged.

lib.rs

  • The propose_parameter_change call site now calls prune_expired_parameter_proposals_bounded directly with MAX_PENDING_PARAMETER_PROPOSALS, making the budget bound visible at the call site rather than hidden inside the helper.

Tests added (test_parameter_governance.rs)

Test What it covers
test_prune_bounded_max_zero_is_noop max_prune = 0 leaves all pending proposals untouched
test_prune_bounded_cap_limits_work_per_call max_prune = 1 prunes only the first expired proposal, leaving the rest pending
test_prune_bounded_prunes_all_when_cap_exceeds_pending_count max_prune >= len prunes everything (same as old behaviour for the normal case)
test_prune_bounded_skips_non_expired_proposals Non-expired proposals are never touched regardless of the cap

Backward compatibility

prune_expired_parameter_proposals keeps its existing signature and behaviour for all callers that already use it (including cleanup_expired_parameter_proposals). The change is purely additive.

Add prune_expired_parameter_proposals_bounded(env, max_prune) to storage.rs
that caps the number of expired proposals processed in a single call.  The
existing prune_expired_parameter_proposals now delegates to the bounded
variant with MAX_PENDING_PARAMETER_PROPOSALS (10) as its cap, and the
propose_parameter_change call site in lib.rs is updated to call the bounded
version directly so the limit is visible at the call site.

This prevents resource-budget exhaustion when many proposals accumulate
without a timely prune and the next propose_parameter_change call triggers
cleanup (Soroban resource limits apply per-transaction).

Tests added to test_parameter_governance.rs:
- test_prune_bounded_max_zero_is_noop
- test_prune_bounded_cap_limits_work_per_call
- test_prune_bounded_prunes_all_when_cap_exceeds_pending_count
- test_prune_bounded_skips_non_expired_proposals

Closes hartz0#265
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant