chore(runway): cherry-pick fix(perps): potential rate limit on close positions cp-7.63.0 cp-7.64.0 cp-7.62.2

[runway-github]

• fix(perps): potential rate limit on close positions cp-7.63.0 cp-7.64.0 cp-7.62.2 (fix(perps): potential rate limit on close positions cp-7.63.0 cp-7.64.0 cp-7.62.2 #25438)

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.

---

Note

Medium Risk
Changes core position-management flows to rely on cached/WebSocket position data and a new optional parameter; incorrect or stale position inputs could cause closes/margin updates to target the wrong size/symbol, though fallbacks remain.

Overview
Prevents 429 rate limiting in HyperLiquid position-management by stopping forced REST refreshes (skipCache: true) in closePositions() and updateMargin(), and relying on cached/WebSocket-backed getPositions().

Extends closePosition() to accept an optional live position object (and updates usePerpsClosePosition + tests to pass it) so closes can skip fetching positions entirely when the caller already has up-to-date WebSocket data.

^{Written by Cursor Bugbot for commit 391e90b. This will update automatically on new commits. Configure here.}

---

Co-authored-by: Michal Szorad michal.szorad@consensys.net 6f89dec

[github-actions]

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.

[github-actions]

🔍 Smart E2E Test Selection

⏭️ Smart E2E selection skipped - base branch is not main (base: release/7.64.0)

All E2E tests pre-selected.

View GitHub Actions results

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

No validation that provided position matches requested symbol

Medium Severity

When params.position is provided, the code uses it directly without validating that params.position.symbol matches params.symbol. The order is placed using params.symbol (line 4040), but position data like size and marginUsed comes from params.position. If a caller passes mismatched values, this could result in placing a close order with the wrong size or for the wrong symbol, potentially causing financial impact. While current callers pass matching data, the API contract permits this inconsistency.

 

[sonarqubecloud]

Quality Gate failed

Failed conditions
75.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud