-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
chore(release): sync stable to main for version 7.65.0 #25471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…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
|
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 detailsE2E Test Selection: Performance Test Selection: |
|
|
Merge my PR |



This PR syncs the stable branch to main for version 7.65.0.
Synchronization Process:
File Preservation:
Preserves specific files from the stable branch:
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.mdto document release7.62.2.Adds a new Fixed section with two rate-limiting related entries, and updates the bottom compare links so
Unreleasednow compares fromv7.62.2and introduces the new7.62.2tag link.Written by Cursor Bugbot for commit 5902e3f. This will update automatically on new commits. Configure here.