[Test] blend-adapter withdraw() overflow panic branch is untested

[collinsezedike]

Description

packages/contracts/blend-adapter/src/lib.rs:301-304 calls b_tokens_to_usdc(shares, reserve.data.b_rate) inside withdraw() and does panic_with_error! on Err. The identical overflow condition is already tested for accrue() (accrue_returns_typed_error_on_overflow, lib.rs:738-749), but no equivalent test drives withdraw() into this same branch.

Acceptance Criteria

• A new test deposits a small amount, sets the mock pool's rate high enough to overflow the conversion, and asserts adapter.withdraw(...) panics with the typed Overflow error (mirroring refresh_panics_on_accrue_overflow's pattern, but for withdraw).
• cargo test -p blend-adapter passes.

[Morrison26-gif]

@Morrison26-gif has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, can i work on this ?

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Morrison26-gif to this issue.

[Rejoice2374]

@Rejoice2374 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Please asssign me, I am desperate to work. I will surely deliver

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Rejoice2374 to this issue.

[rilwanubala]

@rilwanubala has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

hi, please allow me to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @rilwanubala to this issue.

[escaprt]

@escaprt has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I’d like to work on Issue #656 because withdraw() contains an important overflow error path that is currently untested, even though the equivalent conversion failure is already covered in accrue(). Adding this regression test will ensure withdrawal handles extreme pool rates with the expected typed error.

I will first review packages/contracts/blend-adapter/src/lib.rs, specifically the withdraw() conversion around b_tokens_to_usdc(shares, reserve.data.b_rate), and compare it with the existing accrue_returns_typed_error_on_overflow and refresh_panics_on_accrue_overflow tests.

I will then add a focused withdrawal test that deposits a small valid amount to establish adapter state, configures the mock pool with a sufficiently large b_rate to trigger overflow during the share-to-USDC conversion, and calls adapter.withdraw(...).

The test will assert that the operation panics with the typed Overflow error produced by the existing panic_with_error! path. This will verify that an arithmetic conversion failure is surfaced through the contract's intended error mechanism rather than becoming an untyped runtime failure.

I will keep the scenario deterministic by using the existing mock pool and test utilities and will avoid changing the actual withdrawal implementation unless the test exposes an unexpected behavior mismatch.

I will also verify that the setup reaches the conversion branch itself and does not fail earlier due to insufficient shares, missing configuration, or unrelated validation.

Finally, I will run cargo test -p blend-adapter and confirm the complete adapter test suite remains green.

My goal is to give withdraw() direct regression coverage for conversion overflow so the contract consistently returns the expected typed Overflow error under extreme rate conditions, matching the established error-handling behavior elsewhere in the adapter.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @escaprt to this issue.

[drips-wave]

Congratulations, @escaprt! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @escaprt: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊