Skip to content

Conversation

@metamaskbot
Copy link
Collaborator

@metamaskbot metamaskbot commented Jan 30, 2026

This PR syncs the stable branch to main for version 7.65.0.

Synchronization Process:

  • Fetches the latest changes from the remote repository
  • Resets the branch to match the stable branch
  • Attempts to merge changes from main into the branch
  • Handles merge conflicts if they occur

File Preservation:

Preserves specific files from the stable branch:

  • CHANGELOG.md
  • bitrise.yml
  • android/app/build.gradle
  • ios/MetaMask.xcodeproj/project.pbxproj
  • package.json

Indicates the next version candidate of main to 7.65.0


Note

Low Risk
Changelog-only update; no runtime code paths are modified. Risk is limited to incorrect release notes/compare links if mis-specified.

Overview
Updates CHANGELOG.md to document release 7.62.2.

Adds a new Fixed section with two rate-limiting related entries, and updates the bottom compare links so Unreleased now compares from v7.62.2 and introduces the new 7.62.2 tag link.

Written by Cursor Bugbot for commit 5902e3f. This will update automatically on new commits. Configure here.

metamaskbot and others added 10 commits January 30, 2026 13:31
…25443)

## **Description**

Cherry-pick of commit 425beae (Nick's 429 rate limiting fix) to
release/7.62.2 branch.

This hotfix addresses HyperLiquid WebSocket rate limiting issues (429
errors) that occur during rapid market switching or TP/SL updates. The
fix introduces cache-first patterns to reduce API weight and avoid
hitting rate limits.

**Key changes:**
- Add optional `position` parameter to `updatePositionTPSL` to skip REST
API fetch when WebSocket data is available
- Implement `getOrFetchPrice` helper for WebSocket-first price retrieval
(0 weight vs 20 weight)
- Add atomic cache getter `getOrdersCacheIfInitialized()` to prevent
race conditions
- Add `getOrFetchFills` for cache-first fills retrieval
- Move `positionOpenedTimestamp` calculation into
`useHasExistingPosition` hook
- Add `currentPositionRef` sync in PerpsMarketDetailsView to prevent
stale closure issues

**Conflict resolution notes:**
The main branch uses `symbol` naming convention while release/7.62.2
uses `coin`. All conflicts were resolved by keeping the `coin` naming
convention while adopting the cache-first optimization patterns.

## **Changelog**

CHANGELOG entry: Fixed rate limiting issues (429 errors) when rapidly
switching markets or updating TP/SL orders

## **Related issues**

Fixes: Rate limiting issues on HyperLiquid API during rapid market
navigation

## **Manual testing steps**

```gherkin
Feature: Rate limiting prevention for Perps

  Scenario: User rapidly switches between markets
    Given user has the Perps feature enabled
    And user is viewing a market details page

    When user rapidly navigates between different markets (BTC -> ETH -> SOL -> BTC)
    Then no 429 rate limit errors should appear
    And market data should load correctly for each market

  Scenario: User updates TP/SL via stop loss prompt banner
    Given user has an open position without stop loss
    And the stop loss prompt banner is visible

    When user taps "Set Stop Loss" on the banner
    Then the stop loss should be set successfully
    And no rate limit errors should occur

  Scenario: User edits existing TP/SL on a position
    Given user has an open position with TP/SL set

    When user navigates to modify TP/SL
    And user updates the stop loss price
    Then the update should succeed without 429 errors
```

## **Screenshots/Recordings**

### **Before**

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

### **After**

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

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
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.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Touches perps trading/provider logic (`updatePositionTPSL`,
order/price/fill retrieval) and async UI state around stop-loss actions,
so regressions could impact TP/SL updates or stale-data handling, but
changes are bounded and add explicit fallbacks/tests.
> 
> **Overview**
> **Goal:** reduce HyperLiquid REST API weight (and 429s) during rapid
market switching and TP/SL operations by preferring WebSocket caches.
> 
> Adds cache-first primitives in `HyperLiquidSubscriptionService` (fills
cache + atomic `getOrdersCacheIfInitialized`) and `HyperLiquidProvider`
(`getOrFetchPrice`, `getOrFetchFills`), and refactors provider call
sites to use these helpers with stricter invalid-price validation and
single-DEX REST fallbacks.
> 
> Updates TP/SL flow to pass live WebSocket `position` into
`updatePositionTPSL` (avoiding a REST positions fetch), uses cached
orders to cancel existing TP/SL when available, and surfaces
partial-failure feedback in `PerpsOrderView` when order succeeds but
TP/SL update fails.
> 
> Moves `positionOpenedTimestamp` derivation into
`useHasExistingPosition` (WebSocket fills first, REST historical
fallback), and hardens `PerpsMarketDetailsView` stop-loss banner
interactions against stale closures/market switches; the banner UI
switches from a `Switch` to a "Set" button with a delayed success
checkmark + fade-out. Tests and test IDs are updated accordingly.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
0edee81. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Opus 4.5 <[email protected]>
…positions (#25456)

- 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**

```gherkin
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**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding

Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling

guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
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.

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Switches critical trading actions to rely on WebSocket-cached
positions instead of forced REST fetches, which reduces rate limiting
but risks acting on slightly stale position data during rapid state
changes.
> 
> **Overview**
> Reduces HyperLiquid REST pressure during position management by
removing `skipCache: true` position fetches in `closePositions()`,
`closePosition()`, and `updateMargin()`, so these operations prefer the
WebSocket/cache-backed `getPositions()` path.
> 
> This change is aimed at preventing 429 rate limiting during prolonged
app usage when repeatedly closing positions or adjusting margin.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
a84367e. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Michal Szorad <[email protected]>
[6f89dec](6f89dec)

---------

Co-authored-by: abretonc7s <[email protected]>
Co-authored-by: Michal Szorad <[email protected]>
Co-authored-by: Alejandro Garcia <[email protected]>
This PR updates the change log for 7.62.2. (Hotfix - no test plan
generated.)

---------

Co-authored-by: João Loureiro <[email protected]>
# 🚀 v7.62.2 Testing & Release Quality Process

Hi Team,  
As part of our new **MetaMask Release Quality Process**, here’s a quick
overview of the key processes, testing strategies, and milestones to
ensure a smooth and high-quality deployment.

---

## 📋 Key Processes

### Testing Strategy
- **Developer Teams:**  
Conduct regression and exploratory testing for your functional areas,
including automated and manual tests for critical workflows.
- **QA Team:**  
Focus on exploratory testing across the wallet, prioritize high-impact
areas, and triage any Sentry errors found during testing.
- **Customer Success Team:**  
Validate new functionalities and provide feedback to support release
monitoring.

### GitHub Signoff
- Each team must **sign off on the Release Candidate (RC)** via GitHub
by the end of the validation timeline (**Tuesday EOD PT**).
- Ensure all tests outlined in the Testing Plan are executed, and any
identified issues are addressed.

### Issue Resolution
- **Resolve all Release Blockers** (Sev0 and Sev1) by **Tuesday EOD
PT**.
- For unresolved blockers, PRs may be reverted, or feature flags
disabled to maintain release quality and timelines.

### Cherry-Picking Criteria
- Only **critical fixes** meeting outlined criteria will be
cherry-picked.
- Developers must ensure these fixes are thoroughly reviewed, tested,
and merged by **Tuesday EOD PT**.

---

## 🗓️ Timeline and Milestones

1. **Today (Friday):** Begin Release Candidate validation.  
2. **Tuesday EOD PT:** Finalize RC with all fixes and cherry-picks.  
3. **Wednesday:** Buffer day for final checks.  
4. **Thursday:** Submit release to app stores and begin rollout to 1% of
users.
5. **Monday:** Scale deployment to 10%.  
6. **Tuesday:** Full rollout to 100%.

---

## ✅ Signoff Checklist

Each team is responsible for signing off via GitHub. Use the checkbox
below to track signoff completion:

# Team sign-off checklist
- [ ] Mobile Platform

This process is a major step forward in ensuring release stability and
quality. Let’s stay aligned and make this release a success! 🚀

Feel free to reach out if you have questions or need clarification. 

Many thanks in advance

# Reference
- Testing plan sheet -
https://docs.google.com/spreadsheets/d/1tsoodlAlyvEUpkkcNcbZ4PM9HuC9cEM80RZeoVv5OCQ/edit?gid=404070372#gid=404070372
@github-actions
Copy link
Contributor

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.

@metamaskbot metamaskbot added the team-bots Bot team (for MetaMask Bot, Runway Bot, etc.) label Jan 30, 2026
@github-actions
Copy link
Contributor

🔍 Smart E2E Test Selection

  • Selected E2E tags: None (no tests recommended)
  • Selected Performance tags: None (no tests recommended)
  • Risk Level: low
  • AI Confidence: 99%
click to see 🤖 AI reasoning details

E2E Test Selection:
The only change in this PR is an update to CHANGELOG.md, which is a pure documentation file. The changes add release notes for version 7.62.2 (documenting two cherry-picked fixes) and update the version comparison links at the bottom of the file. This is a standard changelog maintenance task that has absolutely no impact on application code, UI components, test infrastructure, or any user-facing functionality. No E2E tests are needed to validate documentation-only changes.

Performance Test Selection:
CHANGELOG.md is a documentation file with no impact on application performance. No code paths, UI rendering, data loading, or any runtime behavior is affected by this change. Performance tests are not needed.

View GitHub Actions results

@sonarqubecloud
Copy link

@joaoloureirop joaoloureirop changed the title release: sync stable to main for version 7.65.0 chore(release): sync stable to main for version 7.65.0 Jan 30, 2026
@joaoloureirop joaoloureirop added the team-mobile-platform Mobile Platform team label Jan 30, 2026
@joaoloureirop
Copy link
Contributor

Merge my PR

@metamaskbotv2 metamaskbotv2 bot merged commit 055c49b into main Jan 30, 2026
73 of 80 checks passed
@metamaskbotv2 metamaskbotv2 bot deleted the stable-main-7.65.0 branch January 30, 2026 22:26
@github-actions github-actions bot locked and limited conversation to collaborators Jan 30, 2026
@metamaskbot metamaskbot added the release-7.65.0 Issue or pull request that will be included in release 7.65.0 label Jan 30, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

release-7.65.0 Issue or pull request that will be included in release 7.65.0 size-XS team-bots Bot team (for MetaMask Bot, Runway Bot, etc.) team-mobile-platform Mobile Platform team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants