Refs #40
File: crates/charon-core/src/queue.rs
PR branch: feat/15-profit-calc-and-queue
Problem:
pop(current_block: u64) and prune_stale(current_block: u64) require the caller to supply the current BSC block number at call time. In the real bot this value flows from BlockListener (charon-scanner) via a tokio watch or broadcast channel. The PR does not show how the executor loop receives and forwards this value.
The 5 unit tests use hardcoded block numbers and do not test:
- Block number provided is stale (behind the actual chain tip by 3+ blocks)
- Same block number provided twice in succession
- Block number decreases (reorg scenario)
For the reorg case: if pop() is called with current_block < entry.inserted_at_block + ttl, a previously-prunable entry becomes eligible again. This is a correctness issue under BSC reorgs (which do occur at depth 1-3).
PRD clause: PRD off-chain gate — stale opportunities must not reach simulation.
Fix: Add a test that simulates a 1-block reorg (block goes from 105 back to 104) and verifies queue behavior is safe. Document the expected usage pattern for the executor loop (e.g., hold tokio::sync::watch::Receiver and call pop(rx.borrow()) on each iteration).
Refs #40
File: crates/charon-core/src/queue.rs
PR branch: feat/15-profit-calc-and-queue
Problem:
pop(current_block: u64) and prune_stale(current_block: u64) require the caller to supply the current BSC block number at call time. In the real bot this value flows from BlockListener (charon-scanner) via a tokio watch or broadcast channel. The PR does not show how the executor loop receives and forwards this value.
The 5 unit tests use hardcoded block numbers and do not test:
For the reorg case: if pop() is called with current_block < entry.inserted_at_block + ttl, a previously-prunable entry becomes eligible again. This is a correctness issue under BSC reorgs (which do occur at depth 1-3).
PRD clause: PRD off-chain gate — stale opportunities must not reach simulation.
Fix: Add a test that simulates a 1-block reorg (block goes from 105 back to 104) and verifies queue behavior is safe. Document the expected usage pattern for the executor loop (e.g., hold tokio::sync::watch::Receiver and call pop(rx.borrow()) on each iteration).