Skip to content

Add regression test FIX#233

Open
Mitch5000 wants to merge 2 commits into
AnchorNet-Org:mainfrom
Mitch5000:Add-regression-test-FIXED
Open

Add regression test FIX#233
Mitch5000 wants to merge 2 commits into
AnchorNet-Org:mainfrom
Mitch5000:Add-regression-test-FIXED

Conversation

@Mitch5000

Copy link
Copy Markdown

TITLE

test: add regression test for deregister/re-register preserving balances and provider counts


DESCRIPTION

Summary

Adds a regression test that explicitly validates the documented behavior of deregister_anchor:

"Existing pool liquidity is unaffected; the anchor simply cannot open new positions."

The test confirms that a deregister → re-register cycle for an anchor that has previously provided liquidity:

  • Leaves balance(), anchor_balances(), and pool.providers completely unchanged
  • Does not reset or double-count providers
  • Allows the anchor to immediately withdraw_liquidity (or withdraw_all_liquidity) using the pre-existing balance
  • Correctly blocks provide_liquidity and open_settlement with AnchorNotRegistered while the anchor is deregistered

No production code changes were required — this closes a test-coverage gap.

Changes

  • Added test_deregister_re_register_preserves_balances_and_provider_count in src/test.rs
  • Test is placed directly after the existing test_list_anchors_reflects_reregistration test (as suggested in the issue)
  • Reuses existing helpers (setup, register_anchor, deregister_anchor, etc.)
  • Covers all acceptance criteria from the issue description

Test Coverage Added

The new test asserts:

  1. Initial state after provide_liquidity
  2. State after deregister_anchor (balances + provider count preserved)
  3. provide_liquidity and open_settlement are rejected with AnchorNotRegistered while deregistered
  4. State after re-register_anchor is identical to before deregistration (no reset, no double-count)
  5. withdraw_all_liquidity succeeds immediately after re-registration using the preserved balance

Motivation / Security Note

As stated in the issue:

If deregistration ever accidentally touched balance state in a future refactor, an anchor's funds could become temporarily or permanently inaccessible purely from an administrative registration action — a serious fund-availability risk this test explicitly guards against.

How to Verify

cargo test test_deregister_re_register_preserves_balances_and_provider_count -- --nocapture
cargo test

Closes #156 

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant