Difficulty: Advanced
Problem
1. advance(env, admin, 0) transitions the queue to AdvancementActive with zero work done
contracts/lineproof-queue/src/lib.rs lines 120–160: the function immediately sets config.status = QueueStatus::AdvancementActive and writes to storage before entering the loop. With batch_size = 0, the loop body never executes, but the status transition and config storage write still occur. The queue permanently transitions to AdvancementActive with nothing advanced.
2. After advance(batch_size: 0), subsequent calls panic with "enrollment must be closed before advancing"
The status is now AdvancementActive (not EnrollmentClosed), so the guard if !matches!(config.status, QueueStatus::EnrollmentClosed) { panic!("enrollment must be closed") } will trigger on all future calls. The queue is stuck in AdvancementActive with all positions still Pending and no way to advance them.
3. The event emission loop also runs for zero iterations — no events emitted, but storage is still modified
The storage write for idx (line 155) and the config write (line 127) still execute even with batch_size = 0. This consumes Soroban fee budget for storage modifications that accomplish nothing.
Impact: An operator who accidentally calls advance(batch_size: 0) permanently bricks the queue — all positions remain Pending forever with no way to advance them. This is a one-way destructive operation with no error.
Proposed Solution
- Add a guard at the start of
advance(): if batch_size == 0 { panic!("batch_size_must_be_positive") }.
- Move the
config.status = AdvancementActive write to after at least one position is successfully advanced (or conditionally, only if the loop produces at least one result).
- Add a test:
#[should_panic(expected = "batch_size_must_be_positive")] for advance(0).
Acceptance Criteria
Contributor Note
If assigned, your PR must also consider whether advance() that produces zero results (all-cancelled batch) should transition to AdvancementActive or remain in EnrollmentClosed, and document the decision.
Difficulty: Advanced
Problem
1.
advance(env, admin, 0)transitions the queue toAdvancementActivewith zero work donecontracts/lineproof-queue/src/lib.rslines 120–160: the function immediately setsconfig.status = QueueStatus::AdvancementActiveand writes to storage before entering the loop. Withbatch_size = 0, the loop body never executes, but the status transition andconfigstorage write still occur. The queue permanently transitions toAdvancementActivewith nothing advanced.2. After
advance(batch_size: 0), subsequent calls panic with "enrollment must be closed before advancing"The status is now
AdvancementActive(notEnrollmentClosed), so the guardif !matches!(config.status, QueueStatus::EnrollmentClosed) { panic!("enrollment must be closed") }will trigger on all future calls. The queue is stuck inAdvancementActivewith all positions still Pending and no way to advance them.3. The event emission loop also runs for zero iterations — no events emitted, but storage is still modified
The storage write for
idx(line 155) and the config write (line 127) still execute even withbatch_size = 0. This consumes Soroban fee budget for storage modifications that accomplish nothing.Impact: An operator who accidentally calls
advance(batch_size: 0)permanently bricks the queue — all positions remain Pending forever with no way to advance them. This is a one-way destructive operation with no error.Proposed Solution
advance():if batch_size == 0 { panic!("batch_size_must_be_positive") }.config.status = AdvancementActivewrite to after at least one position is successfully advanced (or conditionally, only if the loop produces at least one result).#[should_panic(expected = "batch_size_must_be_positive")]foradvance(0).Acceptance Criteria
advance(env, admin, 0)panics with"batch_size_must_be_positive"AdvancementActivewhenadvance()panics on validation#[should_panic(expected = "batch_size_must_be_positive")]test addedAdvancementActiveonly occurs when loop produces ≥1 resultcargo test -p lineproof-queuepasses with zero failuresContributor Note
If assigned, your PR must also consider whether
advance()that produces zero results (all-cancelled batch) should transition toAdvancementActiveor remain inEnrollmentClosed, and document the decision.