Description

Complete the 429 rate limiting fix for position management operations. The previous fix (commit 425beaead7) only addressed updatePositionTPSL(). This PR extends the fix to closePosition(), closePositions(), and updateMargin() methods.

Problem: These methods were using skipCache: true which forced REST API calls on every operation, leading to 429 rate limiting errors during prolonged app usage.

Solution:

• Remove skipCache: true from closePositions() and updateMargin() to use WebSocket cache
• For closePosition(), add optional position parameter so callers can pass the live WebSocket position directly, avoiding the need to fetch positions entirely
• Update usePerpsClosePosition hook to pass the position it already has

Changelog

CHANGELOG entry: Fixed rate limiting errors (429) when closing positions or updating margin after prolonged app usage

Related issues

Fixes: Rate limiting issues during position close/margin update operations

Manual testing steps

Feature: Position close without rate limiting

  Scenario: User closes position after prolonged usage
    Given user has the app open for extended period (>30 minutes)
    And user has an open perps position

    When user closes the position
    Then the position closes successfully without 429 errors

  Scenario: User updates margin after prolonged usage
    Given user has the app open for extended period (>30 minutes)
    And user has an open perps position with isolated margin

    When user adjusts the margin
    Then the margin updates successfully without 429 errors

  Scenario: User closes all positions
    Given user has multiple open perps positions

    When user uses "close all positions" feature
    Then all positions close successfully without rate limiting errors

Screenshots/Recordings

Before

N/A - Bug fix for rate limiting, no UI changes

After

N/A - Bug fix for rate limiting, no UI changes

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.