📌 Description
anchor_balances(provider, start, limit) pages through storage::get_asset_list, which is append-only (new assets are always added at the end via remember_asset). There is no existing test confirming that if a new asset is added (via some other provider's provide_liquidity) between two paginated calls to anchor_balances for a given provider, the provider's in-progress pagination cursor (start) still correctly resumes without skipping or duplicating any of the provider's own existing non-zero balances.
🧩 Requirements and context
- Add a regression test that begins paginating
anchor_balances for a provider with several existing balances, then — between two paginated calls — has a different provider call provide_liquidity for a brand-new asset, then resumes pagination for the first provider and asserts no existing entries were skipped or duplicated.
- Confirm the newly-added asset does not appear in the first provider's results unless that provider also happens to hold a balance in it.
- Document the append-only-list assumption this pagination relies on in
anchor_balances's doc comment if not already explicit.
🛠️ Suggested execution
- Add the test to
src/test.rs near existing anchor_balances coverage.
- Simulate the interleaving explicitly: call
anchor_balances for page 1, then mutate global asset state via a second provider, then call anchor_balances for page 2 using the start cursor returned/inferred from page 1.
- No production code changes expected given
AssetList's append-only design, unless the test uncovers an actual off-by-one at the append boundary.
✅ Acceptance criteria
🔒 Security notes
Silent pagination instability under concurrent asset onboarding would be a frustrating, hard-to-reproduce bug for any off-chain client incrementally rendering a provider's balances while other unrelated activity continues on the contract.
📋 Guidelines
- Minimum 95% test coverage
- Clear documentation
- Timeframe: 96 hours
📌 Description
anchor_balances(provider, start, limit)pages throughstorage::get_asset_list, which is append-only (new assets are always added at the end viaremember_asset). There is no existing test confirming that if a new asset is added (via some other provider'sprovide_liquidity) between two paginated calls toanchor_balancesfor a given provider, the provider's in-progress pagination cursor (start) still correctly resumes without skipping or duplicating any of the provider's own existing non-zero balances.🧩 Requirements and context
anchor_balancesfor a provider with several existing balances, then — between two paginated calls — has a different provider callprovide_liquidityfor a brand-new asset, then resumes pagination for the first provider and asserts no existing entries were skipped or duplicated.anchor_balances's doc comment if not already explicit.🛠️ Suggested execution
src/test.rsnear existinganchor_balancescoverage.anchor_balancesfor page 1, then mutate global asset state via a second provider, then callanchor_balancesfor page 2 using thestartcursor returned/inferred from page 1.AssetList's append-only design, unless the test uncovers an actual off-by-one at the append boundary.✅ Acceptance criteria
anchor_balancespagination remains stable across an asset-list mutation occurring between paginated calls.🔒 Security notes
Silent pagination instability under concurrent asset onboarding would be a frustrating, hard-to-reproduce bug for any off-chain client incrementally rendering a provider's balances while other unrelated activity continues on the contract.
📋 Guidelines