[pull] main from MetaMask:main#571
Merged
Merged
Conversation
…26394) ## **Description** Refactors PerpsController to reduce external npm dependencies and improve portability for publishing to `MetaMask/core`. **Key changes:** - **Move cross-controller types to `types/index.ts`**: `AllowedActions`, `AllowedEvents`, and the new `PerpsControllerMessengerBase` type are defined in the shared types file instead of `PerpsController.ts`, breaking the circular import between services and the controller. - **Services receive messenger directly**: All 6 services (`AccountService`, `DataLakeService`, `DepositService`, `HyperLiquidWalletService`, `RewardsIntegrationService`, `HyperLiquidProvider`) now accept a `PerpsControllerMessengerBase` and call cross-controller actions themselves, instead of receiving the full `PerpsControllerMessenger`. - **Inline external utilities**: `isEvmAccountType` (from `@metamask/keyring-api`) and `formatChainIdToCaip` (from `@metamask/bridge-controller`) are replaced with local implementations to remove those npm dependencies. - **Simplify `getSelectedEvmAccount`**: Now takes an `accounts[]` array directly instead of a messenger, so callers explicitly fetch accounts via `messenger.call('AccountTreeController:getAccountsFromSelectedAccountGroup')`. - **Add local types**: `PerpsTypedMessageParams`, `PerpsTransactionParams`, `PerpsAddTransactionOptions`, `PerpsInternalAccount`, `PerpsRemoteFeatureFlagState` replace imported types from external controller packages. - **Rename rewards DI field**: `rewards.getFeeDiscount` → `rewards.getPerpsDiscountForAccount` to match the actual `RewardsController` method name. - **Clean up messenger delegate**: Removed unused transaction events (`transactionSubmitted`, `transactionConfirmed`, `transactionFailed`) from the delegate list and reordered actions to match the type definition. - **Simplify `mobileInfrastructure`**: Adapter only wires up `rewards` DI (the only field that can't go through the messenger since `RewardsController` is not in Core yet). All other controller access goes through the messenger. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** \`\`\`gherkin Feature: Perps trading after controller refactor Scenario: Trading interface loads correctly Given the app is connected to a supported network When user navigates to the Perps section Then the trading interface loads with market data And account balances and positions are displayed Scenario: Deposit flow works end-to-end Given the user has USDC on the connected chain When user initiates a deposit Then the transaction confirmation screen appears And deposit tracking state is updated after submission Scenario: Signing works for trade execution Given the user has an unlocked keyring When a trade requires a typed signature Then the signature is obtained and the trade executes \`\`\` ## **Screenshots/Recordings** ### **Before** N/A — internal refactor, no UI changes ### **After** N/A — internal refactor, 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.
…6836) <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** Align Bridge native Max-button gasless gating with extension by using Sentinel sendBundle support instead of LD isGaslessSwapEnabled. <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: null ## **Related issues** Fixes: ## **Manual testing steps** ```gherkin Feature: my feature name Scenario: user [verb for user action] Given [describe expected initial app state] When user [verb for user action] Then [describe expected outcome] ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] 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). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] 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** > Changes the Bridge native-token Max-button eligibility logic to depend on Sentinel `sendBundle` support (plus Smart Transactions/sponsored quotes), which can alter when users are allowed to max native balances on different chains. > > **Overview** > Aligns Bridge native-token Max-button rendering with extension by replacing the `selectIsGaslessSwapEnabled` feature-flag check with a Sentinel-based `useIsSendBundleSupported` check, using a memoized EVM-only `chainId` (non-EVM passes `undefined`). > > Updates and heavily simplifies `useShouldRenderMaxOption` tests to mock `useIsSendBundleSupported`/`isNonEvmChainId`/`formatChainIdToHex`, and to validate the new native-token truth table and chain-id wiring. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit be560bf. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** This PR introduces `useTokensBuyability(tokens)` to evaluate buyability for multiple tokens in a single hook call, and keeps `useTokenBuyability(token)` as a backward-compatible convenience wrapper over the batch hook. `useTokensBuyability` returns buyability as `buyabilityByTokenKey` (keyed by normalized chain + token address). Motivation: reduce redundant legacy ramp token fetches when checking multiple tokens in the same render path. Previously, calling `useTokenBuyability` N times could trigger repeated legacy useRampTokens mount-driven fetch behavior. This change also preserves V2 efficiency by passing `fetchOnMount: !isV2Enabled`, so the legacy fetch is suppressed when unified buy V2 is enabled and controller-backed tokens are used. <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> ## **Changelog** <!-- If this PR is not End-User-Facing and should not show up in the CHANGELOG, you can choose to either: 1. Write `CHANGELOG entry: null` 2. Label with `no-changelog` If this PR is End-User-Facing, please write a short User-Facing description in the past tense like: `CHANGELOG entry: Added a new tab for users to see their NFTs` `CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker` (This helps the Release Engineer do their job more quickly and accurately) --> CHANGELOG entry: refactored Ramp buyability to add batched useTokensBuyability with keyed results and keep useTokenBuyability as a backward-compatible wrapper, reducing redundant legacy token-cache fetches for multi-token checks. ## **Related issues** Fixes: [MUSD-282: mUSD Asset List CTA is spamming the Ramps Tokens API endpoint](https://consensyssoftware.atlassian.net/browse/MUSD-282) ## **Manual testing steps** ```gherkin Feature: Batched Ramp token buyability checks Scenario: user views mUSD eligibility Given user is on a screen that evaluates multiple token buyability states (e.g. Token List) Then the app checks buyability of multiple tokens in one hook call ``` ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** N/A <!-- [screenshots/recordings] --> ### **After** When `MM_RAMPS_UNIFIED_BUY_V2_ENABLED="true"` `useMusdRampAvailability` leverages ramp token cache. <!-- [screenshots/recordings] --> ## **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** > Changes Ramp buyability evaluation and when the legacy token-cache API is fetched; regressions could hide/show buy CTAs incorrectly or delay buyability data if the new fetch gating is misused. > > **Overview** > Introduces `useTokensBuyability(tokens)` and supporting helpers (e.g., `getTokenBuyabilityKey`) to compute Ramp buyability for multiple tokens in one hook call, while keeping `useTokenBuyability(token)` as a backward-compatible wrapper. > > Adds a `fetchOnMount` option to `useRampTokens` and uses it from buyability logic to **skip legacy token-cache fetching when Unified Ramps V2 is enabled**, reducing repeated API calls. > > Refactors `useMusdRampAvailability` to derive per-chain mUSD buyability via `useTokensBuyability` (using mUSD token addresses per chain), and updates/expands tests across Ramp and Earn hooks to cover the new batching and fetch gating behavior. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 437bc20. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Adds `orderType` (FOK or FAK) to the Predict trade analytics events so we can track which order type is being used when users place orders. The order type is determined at preview time based on feature flags (`permit2Enabled`, `executors`, `fakOrdersEnabled`) and current Permit2 allowance state, then included on the `OrderPreview`. The controller reads `preview.orderType` and passes it to all three `trackPredictOrderEvent` calls (submitted, succeeded, failed). > **Note:** A temporary `hasPermit2Allowance()` check is included in `previewOrder()` as a workaround. This will be removed in a follow-up PR once `placeOrder()` guarantees the Permit2 allowance is set automatically before order submission. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/PRED-721 ## **Manual testing steps** ```gherkin Feature: Order type analytics tracking Scenario: user places a FOK order Given the predict feature is enabled with default flags (permit2 disabled) When user previews and places an order Then the analytics event includes order_type: "FOK" for submitted, succeeded, and failed statuses Scenario: user places a FAK order Given the predict feature is enabled with permit2Enabled, executors configured, and fakOrdersEnabled all true And the user has Permit2 allowance set When user previews and places an order Then the analytics event includes order_type: "FAK" for submitted, succeeded, and failed statuses ``` ## **Screenshots/Recordings** <!-- Not applicable — analytics-only change with no UI impact --> ### **Before** <!-- N/A --> ### **After** <!-- N/A --> ## **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 - [ ] 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** > Changes Polymarket `previewOrder`/`placeOrder` logic that determines `orderType` (FOK vs FAK), which can affect how trades are submitted/executed under Permit2/fee-collection conditions. While covered by new unit tests and largely additive for analytics, mistakes here could lead to incorrect order submission behavior or fee handling. > > **Overview** > Predict trade analytics now optionally include **`order_type` (FOK/FAK)** via a new `PredictEventProperties.ORDER_TYPE` key and a `PredictOrderType` type, with `PredictController.trackPredictOrderEvent` accepting/passing this value for submitted/succeeded/failed events. > > Polymarket order flow is updated to **compute `orderType` during `previewOrder()`** (default FOK; switch to FAK when Permit2 config + `fakOrdersEnabled`, and Permit2 allowance is ready only when fees require it) and to **use that computed order type in `placeOrder()`**; related Permit2 allowance checks are wrapped with logging/fallback, executor selection now uses `crypto.getRandomValues`, and tests are expanded to validate order-type behavior and analytics property inclusion. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit 4aa81a4. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY -->
<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->
## **Description**
The purpose of this PR is to add E2E smoke test coverage for the Unified
Buy V2 flow, validating both routing paths a user can take when
purchasing crypto through the ramps experience.
- Two smoke test scenarios: new user (no prior completed orders) routes
through the native Transak deposit flow (KYC/OTP + bank transfer);
returning user (prior non-Transak aggregator order) routes through the
aggregator WebView buy flow
- New page objects: KYCScreen, OrderDetailsView, ActivitiesView,
ToastModal, extended BuildQuoteView
- Full Transak native flow mocking: auth/login, auth/verify, quotes,
user details, KYC requirements, user limits, create order
- Ramps mock infrastructure refactor: introduced setupDepositOnRampMocks
and setupBuyOnRampMocks as single-purpose helpers;
-
setupRegionAwareOnRampMocks retained as the base for build-quote-only
tests; default providerType corrected from native to aggregator
- TestID additions: crypto/fiat amount testIDs moved to
DisplayOrderListItem (the actually-rendered component), testIDs added to
EnterEmail, OtpCode, VerifyIdentity, and ActivitiesView; removed dead
OrdersListTestIds aggregate export
## **Changelog**
<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`
If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`
(This helps the Release Engineer do their job more quickly and
accurately)
-->
CHANGELOG entry:
## **Related issues**
Fixes:
## **Manual testing steps**
```gherkin
Feature: my feature name
Scenario: user [verb for user action]
Given [describe expected initial app state]
When user [verb for user action]
Then [describe expected outcome]
```
## **Screenshots/Recordings**
<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->
### **Before**
<!-- [screenshots/recordings] -->
### **After**
<!-- [screenshots/recordings] -->
## **Pre-merge author checklist**
- [ ] 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).
- [ ] 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](https://jsdoc.app/) format
if applicable
- [ ] 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**
> Mostly E2E test, selector, and mock refactors, but it substantially
changes the on-ramp mocking setup and fixtures used across ramps smoke
tests, which could cause test flakiness or broken flows if assumptions
drift.
>
> **Overview**
> Adds end-to-end smoke coverage for Unified Buy V2 across both routing
paths: **new users** go through the native Transak KYC/OTP deposit flow,
while **returning users** go through the aggregator (widget/WebView) buy
flow, including verification of the resulting order in the Activity
transfers list and basic analytics assertions.
>
> Refactors ramps API mocking to provide dedicated helpers
(`setupDepositOnRampMocks`, `setupBuyOnRampMocks`) and expands mocked
endpoints for the native Transak flow (auth, quotes, user/KYC/limits,
order creation, translation, and stateful order polling), while
splitting buy vs deposit order-status mocking.
>
> Improves Detox automation by adding/centralizing `testID` selectors
for ramps screens (`EnterEmail`, `OtpCode`, `VerifyIdentity`,
`OrderDetails`) and for `OrdersList` rows/amounts, plus new page objects
(`KYCScreen`, `OrderDetailsView`) and enhanced page object actions
(e.g., wait-for-enabled Continue).
>
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
0b768fe. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…AYMENT_METHOD_SELECTED (#26531) ## **Description** Removes the `offramp-cashout.failing.ts` e2e test and closes the coverage gap with a new unit test as part of [MMQA-1492](https://consensyssoftware.atlassian.net/browse/MMQA-1492). The e2e test was fully skipped (`describe.skip`) and covered two behaviors on the Aggregator offramp `BuildQuote` screen: 1. **Payment method selection** — tapping the payment method dropdown and switching from "Debit or Credit" to "SEPA Bank Transfer" 2. **Analytics event tracking** — `OFFRAMP_PAYMENT_METHOD_SELECTED` event fires with correct properties (`payment_method_id`, `available_payment_method_ids`, `region`, `location`) **Existing coverage** in `PaymentMethodSelectorModal.test.tsx`: - `'tracks RAMPS_PAYMENT_METHOD_SELECTED event when payment method is selected'` — fires the event with all required properties (buy flow) - `'does not track RAMPS_PAYMENT_METHOD_SELECTED event when the same payment method is selected'` — guards against duplicate events - `'renders for sell flow'` — snapshot test with `isBuy: false` **Coverage gap identified:** The existing analytics test only exercised `isBuy: true`, so the `OFFRAMP_PAYMENT_METHOD_SELECTED` event name branch was never tested. The payload shape was already covered since it's identical for both flows. **Gap closed:** Added a new unit test case with `isBuy: false` that asserts `OFFRAMP_PAYMENT_METHOD_SELECTED` fires with the correct payload. The `isBuy` ternary branch is now fully covered. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1492 ## **Manual testing steps** ```gherkin Feature: Ramps offramp-cashout e2e removal with coverage gap closed Scenario: user verifies offramp analytics event coverage Given the metamask-mobile repository is checked out on the PR branch When user runs yarn test app/components/UI/Ramp/Aggregator/components/PaymentMethodSelectorModal/PaymentMethodSelectorModal.test.tsx Then all unit tests pass And the test "tracks OFFRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in sell flow" passes And the test "tracks ONRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in buy flow" passes And the test "does not track ONRAMP_PAYMENT_METHOD_SELECTED event when the same payment method is selected" passes ``` ## **Screenshots/Recordings** ### **Before** 5 tests in `PaymentMethodSelectorModal.test.tsx`: - `renders correctly` - `renders without disclaimer when selected payment method has none` - `renders for sell flow` - `tracks RAMPS_PAYMENT_METHOD_SELECTED event when payment method is selected` — misnamed, only tested buy flow - `does not track RAMPS_PAYMENT_METHOD_SELECTED event when the same payment method is selected` — misnamed The `isBuy: false` branch (`OFFRAMP_PAYMENT_METHOD_SELECTED`) was never exercised. Test names did not match the actual events being asserted. ### **After** 6 tests in `PaymentMethodSelectorModal.test.tsx`: - `renders correctly` - `renders without disclaimer when selected payment method has none` - `renders for sell flow` - `tracks OFFRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in sell flow` — **new**, covers `isBuy: false` with realistic `location: 'Amount to Sell Screen'` - `tracks ONRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in buy flow` — **renamed** to match actual assertion - `does not track ONRAMP_PAYMENT_METHOD_SELECTED event when the same payment method is selected` — **renamed** to match actual assertion ## **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 - [ ] 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. [MMQA-1492]: https://consensyssoftware.atlassian.net/browse/MMQA-1492?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Test-only changes: adds/renames unit tests for onramp/offramp analytics and removes a fully skipped smoke e2e, with no production logic changes. > > **Overview** > Adds unit test coverage in `PaymentMethodSelectorModal.test.tsx` to assert the sell flow fires `OFFRAMP_PAYMENT_METHOD_SELECTED`, and renames existing assertions to explicitly reference `ONRAMP_PAYMENT_METHOD_SELECTED`. > > Removes the fully skipped `offramp-cashout.failing.ts` smoke test that previously attempted to validate off-ramp payment method selection and analytics. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit f166a54. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )