chore: Fix stuck pending withdraw #24214
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsThe changes are entirely scoped to the Perps (Perpetuals trading) feature:
The changes use Risk is medium because:
Only the SmokePerps tag is needed as all changes are isolated to the Perpetuals trading feature. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| const isAmountMatch = amountDiff < 0.01; | ||
| const isAssetMatch = pending.asset === completed.asset; | ||
|
|
||
| return isAmountMatch && isAssetMatch; |
There was a problem hiding this comment.
Multiple same-amount withdrawals match incorrectly or stay stuck
Medium Severity
The matching logic uses find() which always returns the first matching element, but there's no tracking of which completed withdrawals have already been matched. When a user makes multiple withdrawals with the same amount and asset (e.g., two 100 USDC withdrawals), all pending withdrawals will match the first completed withdrawal via find(), displaying the wrong txHash for subsequent withdrawals. Additionally, in the useEffect, multiple completed withdrawals will all try to match the first pending one, but updatedWithdrawalIdsRef only tracks pending IDs—causing subsequent completed withdrawals to be blocked, leaving their corresponding pending withdrawals stuck indefinitely. Removing the timestamp constraint makes this more likely since any same-amount withdrawals now match regardless of when initiated.
Additional Locations (1)
| parseFloat(pending.amount) - parseFloat(completed.amount), | ||
| ); | ||
| return amountDiff < 0.01 && pending.asset === completed.asset; | ||
| }); |
There was a problem hiding this comment.
Duplicate entries appear after withdrawal marked completed
Medium Severity
After a withdrawal is matched and its controller state is updated to status: 'completed', subsequent renders create duplicate entries. The first loop adds the controller's completed withdrawal (lines 273-276). The second loop's hasPendingMatch check only looks for withdrawals with status === 'pending' || 'bridging' (lines 287-290). Since the controller withdrawal is now 'completed', it doesn't count as a match, so the API's version of the same withdrawal is added separately. Users see two entries for the same withdrawal with different IDs but the same txHash and amount.
Additional Locations (1)
|
Description
Withdrawal indicators in Perps could get stuck in "pending" or "bridging" state indefinitely, even after the withdrawal had successfully completed on-chain. This created a poor user experience where users saw stale pending indicators that never resolved.
Solution
Enhanced the 1useWithdrawalRequests1 hook to automatically reconcile pending withdrawal states with completed withdrawals from the HyperLiquid API:
Account isolation: Filters withdrawals by the current selected account to prevent showing stale indicators from other accounts
Changelog
CHANGELOG entry: Fixed an issue where Perps withdrawal indicators could remain stuck in "pending" state after the withdrawal completed
Related issues
Fixes: https://consensyssoftware.atlassian.net/browse/TAT-2128
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Adds a new hook and strengthens withdrawal state reconciliation for Perps.
usePerpsMarketFillsmerges WebSocket (usePerpsLiveFills) and RESTgetOrderFillsdata with deduplication, symbol filtering, descending timestamp sort, refresh support, and optionalthrottleMs(defaults to 0)useWithdrawalRequestsnow matches completions by amount (±$0.01) and asset (timestamp constraint removed); updates controller viaupdateWithdrawalStatusin a side-effect with dedup tracking (useRef)Written by Cursor Bugbot for commit 7692dba. This will update automatically on new commits. Configure here.