M-22. Strategy Vault stuck at `withdraw_failed` status if the deposit to `GMX` get Cancelled

• If adding liquidity to GMX get canceled after a failed withdrawal, the contract stuck in the withdraw_failed status.

• The status withdraw_failed is set when the vault successfully withdrew from GMX, but the callback failed during the processWithdraw() checks inside the try call, as seen here:

plain text
function processWithdraw(GMXTypes.Store storage self) external {

GMXChecks.beforeProcessWithdrawChecks(self);// revert if status not withdraw
try GMXProcessWithdraw.processWithdraw(self) {
////... some code
} catch (bytes memory reason) {
// withdraw failed only can be set here .
>>          self.status = GMXTypes.Status.Withdraw_Failed;
emit WithdrawFailed(reason);
}
}

plain text
function processWithdrawFailure(GMXTypes.Store storage self, uint256 slippage, uint256 executionFee) external {
GMXChecks.beforeProcessAfterWithdrawFailureChecks(self);

// Re-borrow assets based on the repaid amount
>>    GMXManager.borrow(
self, self.withdrawCache.repayParams.repayTokenAAmt, self.withdrawCache.repayParams.repayTokenBAmt
);
//......
}

plain text
function processWithdrawFailure(GMXTypes.Store storage self, uint256 slippage, uint256 executionFee) external {
GMXChecks.beforeProcessAfterWithdrawFailureChecks(self);

// Re-borrow assets based on the repaid amount
GMXManager.borrow(
self, self.withdrawCache.repayParams.repayTokenAAmt, self.withdrawCache.repayParams.repayTokenBAmt
);
// .... some code

// Re-add liquidity with all tokenA/tokenB in vault
>>      self.withdrawCache.depositKey = GMXManager.addLiquidity(self, _alp);
}

Even if the keeper can call this without any event listening, doing so exacerbates the situation. It results in a loop of borrow more => add liquidity => get canceled, continuing until there are no more funds to borrow or the keeper runs out of gas.

• Another issue arises when there is insufficient funds in the lending contract for borrowing, as this function does not check the capacity before borrowing. This results in repeated reverting transactions since the amount the keeper want to borrow is more then the amount available in the lending contract.

• Renders users unable to withdraw or deposit funds, halting essential interactions with the protocol.

• Poses a risk of failing to rebalance the contract, potentially resulting in bad debt accumulation.

• In the afterWithdrawalCancellation() function of the callback contract, implement proper handling for canceled liquidity addition when the status is withdraw_Failed.