📌 Description
open_settlement assigns ids via storage::get_settlement_count(&env) + 1, then immediately persists the incremented counter, which should guarantee ids are assigned strictly monotonically with no gaps or reuse regardless of how many settlements are subsequently executed, cancelled, or expired. There is no property-style test explicitly fuzzing a long, randomized sequence of open_settlement calls interleaved with execute_settlement/cancel_settlement/cancel_expired_settlement calls and asserting the id sequence itself (independent of status) remains strictly monotonic and gapless.
🧩 Requirements and context
- Add a
proptest-based test generating a randomized sequence of settlement lifecycle operations across multiple assets and anchors.
- Track every id returned by
open_settlement in the test and assert the sequence is exactly 1, 2, 3, ... with no gaps or repeats, regardless of how many of those settlements are later executed/cancelled/expired.
- Assert
settlement_count() always equals the number of open_settlement calls made so far, never more or less.
🛠️ Suggested execution
- Add the proptest to
src/test.rs, reusing the crate's existing proptest dev-dependency.
- Keep the operation-generation strategy simple: a bounded list of
(asset, anchor) pairs and a small set of lifecycle actions to interleave.
- Document the monotonic-id invariant being tested in a comment above the proptest.
✅ Acceptance criteria
🔒 Security notes
A gap or repeat in settlement ids would break every id-keyed off-chain index and could, in the worst case, let two distinct settlements collide on the same id — this property test is cheap insurance against that class of bug given the counter's simple but easy-to-regress increment-then-persist pattern.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
open_settlementassigns ids viastorage::get_settlement_count(&env) + 1, then immediately persists the incremented counter, which should guarantee ids are assigned strictly monotonically with no gaps or reuse regardless of how many settlements are subsequently executed, cancelled, or expired. There is no property-style test explicitly fuzzing a long, randomized sequence ofopen_settlementcalls interleaved withexecute_settlement/cancel_settlement/cancel_expired_settlementcalls and asserting the id sequence itself (independent of status) remains strictly monotonic and gapless.🧩 Requirements and context
proptest-based test generating a randomized sequence of settlement lifecycle operations across multiple assets and anchors.open_settlementin the test and assert the sequence is exactly1, 2, 3, ...with no gaps or repeats, regardless of how many of those settlements are later executed/cancelled/expired.settlement_count()always equals the number ofopen_settlementcalls made so far, never more or less.🛠️ Suggested execution
src/test.rs, reusing the crate's existingproptestdev-dependency.(asset, anchor)pairs and a small set of lifecycle actions to interleave.✅ Acceptance criteria
settlement_count()always matches the number ofopen_settlementcalls made.🔒 Security notes
A gap or repeat in settlement ids would break every id-keyed off-chain index and could, in the worst case, let two distinct settlements collide on the same id — this property test is cheap insurance against that class of bug given the counter's simple but easy-to-regress increment-then-persist pattern.
📋 Guidelines