Migrate tron wallet snap into merged-packages#45
Merged
Conversation
This is the release candidate for version 1.4.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
This reverts commit 5c74f2d.
This is the release candidate for version 1.3.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
- Always return the default native asset. - Miscellaneous fixes - Pass the correct metadata - Fix extractTrc10Assets and how the assets were handled
This is the release candidate for version 1.4.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Antonio Regadas <antonio.regadas@consensys.net>
Notice the fields that are already being sent to the client <img width="724" height="785" alt="Screenshot 2025-10-17 at 11 58 57" src="https://github.com/user-attachments/assets/4da9ab06-5abc-4b48-b25f-091f901c8547" />
This is the release candidate for version 1.5.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
Add `maximunEnergyTokensMetadata` and `maximunBandwidthTokensMetadata`.
…esh service (#342) ## Explanation This pull request refactors how transaction payloads are handled during the sign transaction refresh process, improving safety and correctness when dealing with expired transactions. The main changes focus on ensuring the original transaction payload is never modified, handling deserialization errors gracefully, and surfacing transaction expiration status more reliably in the UI. Additionally, the test suite has been updated to cover these new behaviors, and localized error messages have been added. **Transaction handling improvements:** * The sign transaction refresh flow no longer modifies the original dApp transaction payload; instead, it always rescans the unmodified payload, ensuring that expiration and TAPOS status are surfaced without altering the transaction. * The scan now uses a deserialized version of the original payload for both security scanning and local TAPOS-expiry checks. If deserialization fails, the error is logged and tracked, and scanning is skipped to avoid further issues. **Error handling and test coverage:** * Comprehensive tests were added and updated to verify that: - The transaction payload is not modified during refresh. - Error states are correctly set when scans or deserialization fail. - TAPOS expiry is detected and surfaced in the UI, even if the security scan is disabled. - Errors in TAPOS checks do not erase benign scan results. **Localization and user feedback:** * New error messages for transaction deadline/expiration have been added to English and Spanish locale files, as well as the main messages file, to provide clear feedback to users. **Code and configuration updates:** * Unused or obsolete code paths related to refreshing serialized transactions were removed from the codebase and test mocks, simplifying the implementation. * Jest coverage thresholds were slightly increased to reflect improved test coverage. **Manifest and dependency updates:** * The Snap manifest hash was updated to reflect the new build. These changes make the transaction signing process safer, more predictable, and easier to debug, while also improving the user experience and test reliability. <img width="388" height="1277" alt="expired" src="https://github.com/user-attachments/assets/b613a097-2baa-4f3c-a204-8f49e6379a54" /> ## References WPN-1381 ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes core dApp sign/confirm behavior (no more silent TAPOS refresh) and transaction UX gating; mistakes could allow signing unbroadcastable txs or break dApp broadcasts, though behavior is heavily tested. > > **Overview** > **dApp signing no longer rewrites transactions.** `KeyringHandler`, `WalletService`, and the sign-transaction cron refresh stop calling payload refresh (`ensureFreshSerializedTransaction` / pre-sign `ensureFreshMetadata`). The snap validates and signs the **exact** `rawDataHex` the dApp submitted so the signature still matches the dApp’s TxID at broadcast. > > **Expiry is detected without changing bytes.** `TransactionExpirationRefresherService` gains read-only `deserializeTransaction` and `isTransactionExpired`; refresh flows rescan the **original** deserialized payload and may override a benign security scan with `EXPIRED_TRANSACTION_SCAN` (`TransactionTaposExpired`). Confirm UI shows a friendly “Please go back and try again” message, disables confirm on failed simulation, and still shows the expiry banner when security alerts are off. > > **Operational polish:** background refresh scheduling is best-effort (failures don’t wipe scan state), deserialization/TAPOS errors are tracked via `trackError`, and `ensureFreshMetadata` remains for **snap-initiated** send paths only. Locales, changelog, manifest shasum, and Jest coverage thresholds are updated accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 97269475c4e98087c1bff35d71c88288b8ed9e31. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This is the release candidate for version 1.29.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Frederic HENG <frederic.heng@consensys.net>
## Explanation This pull request enhances the robustness and flexibility of the `PriceApiClient` and its tests, improves schema validation for spot prices, and updates coverage thresholds. The main changes include improved error handling and logging in the client, expanded test coverage for edge cases, and a more permissive schema for handling unknown fields from the Price API. **Testing improvements:** * Added tests to `PriceApiClient.test.ts` to verify logging and error throwing when the response is not OK, when fetch fails, and when the cache returns unexpected keys. [[1]](diffhunk://#diff-10c2d03a01358c0fb445e725c788d111883688d8bc211c03ae0869fce6d3f067R62-R89) [[2]](diffhunk://#diff-10c2d03a01358c0fb445e725c788d111883688d8bc211c03ae0869fce6d3f067R288-R299) **Schema validation enhancements:** * Updated `SpotPriceStruct` to use `typeStruct` instead of `object`, allowing unknown fields from the Price API without throwing validation errors. [[1]](diffhunk://#diff-0ec11ee8d6afb4d9b0c603a9277674dd1dd5795a11a7ac795c80f3f13ea2290dR15) [[2]](diffhunk://#diff-0ec11ee8d6afb4d9b0c603a9277674dd1dd5795a11a7ac795c80f3f13ea2290dL153-R154) * Added a test to ensure that unknown fields in spot prices do not cause validation to fail. **Error handling and code consistency:** * Removed default values for the `vsCurrency` parameter in internal methods of `PriceApiClient`, requiring explicit specification. [[1]](diffhunk://#diff-640aa283fb35e4c99bf06a40f47177b59d21cc98cbd381deb8e391ee731fd224L101-L107) [[2]](diffhunk://#diff-640aa283fb35e4c99bf06a40f47177b59d21cc98cbd381deb8e391ee731fd224L182-R178) **Configuration updates:** * Increased Jest coverage thresholds for branches, lines, and statements in `jest.config.js`. * Updated the `shasum` in `snap.manifest.json` to reflect the new build. BEFORE: <img width="1604" height="273" alt="coverage after" src="https://github.com/user-attachments/assets/954ad728-936f-4dab-a8be-47f01f777447" /> AFTER: <img width="1622" height="280" alt="coverage" src="https://github.com/user-attachments/assets/0167b828-45a2-40e3-b911-8f344d2e10a5" /> ## References Fixes: WPN-1526 ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Changes are limited to schema permissiveness, tests, and build metadata; public spot-price behavior is unchanged aside from stricter internal vsCurrency wiring. > > **Overview** > Fixes spot price validation failing when the Price API adds extra fields by switching **`SpotPriceStruct`** from strict `object` to **`typeStruct`**, so unknown keys are ignored while required fields stay validated. A matching struct test confirms extra properties no longer break **`assert`**. > > **`PriceApiClient`** tests now cover fiat exchange rate HTTP failures, network errors, and malformed cache keys (`Invalid cache key`). Internal spot-price helpers no longer default **`vsCurrency`** or short-circuit on empty token lists (callers still get **`usd`** from the public **`getMultipleSpotPrices`**). Jest coverage thresholds and **`snap.manifest.json`** **`shasum`** are bumped for the new build. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit f5e4f6d4dc1a8c1e19ee6a306a8f3ae5b7bd3537. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This is the release candidate for version 1.29.1. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Frederic HENG <frederic.heng@consensys.net>
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> The cronjob interval for account syncing is being increased from 30 seconds to 60 seconds. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Configuration-only timing change with no handler logic edits; balances and history may refresh slightly less frequently. > > **Overview** > Doubles the **`endowment:cronjob`** interval for **`onSynchronizeSelectedAccountsCronjob`** from **30s** (`PT30S`) to **60s** (`PT60S`) in **`snap.manifest.json`**, so selected-account background sync runs half as often. > > The **[Unreleased]** changelog entry documents the change, and the manifest **`source.shasum`** is updated to match the rebuilt bundle. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3d35f6f850545033bb05474c049537d832da56f3. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This is the release candidate for version 1.30.0. --------- Co-authored-by: github-actions <github-actions@github.com>
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This PR is an improvement for the #280. Basically has been introduced a new variable `FALLBACK_FEE` used only during the `computeFee` step related to a Swap operation (executed by `signAndSendTransaction` request). This is needed because transactions that involve an `approve` step before are NOT estimated, their transactions are impossible at the current state of the blockchain so currently we are using the value of the constant `FEE_LIMIT` as `fee_limit` parameter. This leads to an extremely high fees computed and, most of the time, the user decides to not proceed with the swap operation. After an analysis of on-chain data, we have calculated `37 TRX` as an acceptable value to be used for the fee calculation. The broadcasted transaction still uses the `FEE_LIMIT` value for setting the `fee_limit` in the built transaction. Additionally the `FEE_LIMIT` value has been increased to `101 TRX` to allow us to filter easly the transactions sent through MetaMask. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Before https://github.com/user-attachments/assets/d4fdf254-4ce7-4407-b951-0e6a4b980dde ## After https://github.com/user-attachments/assets/2f54b538-b821-496f-b0c6-2730c1d391a0 ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > All `computeFee` responses now use a fixed 37 TRX cap for calculator input, which can understate fees for some txs while broadcast still allows up to 101 TRX. > > **Overview** > Swap and similar flows often ship transactions with a **101 TRX** `fee_limit` because on-chain simulation cannot estimate approve-heavy steps. **`computeFee`** was feeding that limit into `FeeCalculatorService`, which produced unrealistically high TRX fees and discouraged users from continuing. > > This change introduces **`FALLBACK_FEE` (37 TRX in SUN)** and passes it as the `feeLimit` argument when **`ClientRequestHandler`** handles **`ComputeFee`**, instead of the transaction’s `raw_data.fee_limit`. **`FEE_LIMIT`** is raised from **100 → 101 TRX** for broadcast/sign paths (e.g. **`signAndSendTransaction`**) so MetaMask-originated txs stay identifiable. Tests and the snap changelog/manifest shasum are updated accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e645c4f67d4370143459131a8ae60a071f3e25d5. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This is the release candidate for version 1.31.0. --------- Co-authored-by: github-actions <github-actions@github.com>
…om a dApp (#355) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This PR fixes Tron dApp transaction confirmations so fee/resource information and balance validation are more accurate. - Display estimated ENERGY and BANDWIDTH usage in the transaction confirmation even when those resources are covered by available/free/staked resources. - Show the full estimated energy and bandwidth usage, while charging TRX only for the portion not covered by the user’s available resources. - Add insufficient-balance detection for dApp transaction confirmations by comparing: - native TRX transferred by the transaction - estimated TRX fees - current native TRX balance - Disable the confirmation button and show an `Insufficient funds` banner when the account cannot cover the transaction value plus fees. - Add `getTransactionTrxValue` helper to extract native TRX value from: - `TransferContract.amount` - `TriggerSmartContract.call_value` - Update confirmation context types to include `isInsufficientBalance`. - Update/add tests for fee calculation, transaction TRX value extraction, confirmation rendering, and insufficient-balance UI behavior. - Followed guidelines to [avoid the usage of beforeEach](https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Before ### Send <img width="966" height="1286" alt="WPN-454 Before - Send" src="https://github.com/user-attachments/assets/3e24a5d5-5580-46f3-b55a-3c5d4754b9ae" /> ### Swap <img width="992" height="1288" alt="WPN-454 Before - Swap" src="https://github.com/user-attachments/assets/44728ee6-b8ed-468d-b286-a4ce799b4126" /> ### dApp - Enough funds <img width="586" height="718" alt="WPN-454 Before - dApp - Enough funds" src="https://github.com/user-attachments/assets/48871f99-ddaa-4f49-ae14-044013266eaa" /> ### dApp - Insufficient funds <img width="936" height="744" alt="WPN-454 Before - dApp - Insufficient funds" src="https://github.com/user-attachments/assets/965abb0c-c925-458a-b7a0-4e5e0a74f1fd" /> ## After ### Send <img width="775" height="1282" alt="WPN-454 After - Send" src="https://github.com/user-attachments/assets/3e4c60e6-bd20-4c97-b313-39c6d9df7fe4" /> ### Swap <img width="775" height="1282" alt="WPN-454 After - Swap" src="https://github.com/user-attachments/assets/26f33fc3-9d0c-421e-b667-5d41364c82a8" /> ### dApp - Enough funds <img width="627" height="780" alt="WPN-454 After - dApp - Enough funds" src="https://github.com/user-attachments/assets/c3b8f3e1-607d-453d-9afd-524947cd7a6d" /> ### dApp - Insufficient funds <img width="947" height="818" alt="WPN-454 After - dApp - Insufficient funds" src="https://github.com/user-attachments/assets/bcfd88f7-00f9-4536-a977-6d1885ab3171" /> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes fee presentation and pre-sign balance gating on the confirmation path; incorrect estimates or balance checks could mislead users or block valid transactions. > > **Overview** > Improves **dApp sign-transaction confirmations** by aligning fee breakdowns with what the transaction will actually use, and by blocking confirm when native balance cannot cover value plus fees. > > **Fee display:** `FeeCalculatorService.computeFee` still charges **TRX only for bandwidth/energy shortfalls** (plus activation/memo), but the returned fee list now always includes **full estimated ENERGY and BANDWIDTH** amounts when the tx needs them—not only the portion drawn from staked/free resources. Confirmations can show resource usage even when it is fully covered. > > **Insufficient balance:** Confirmation context gains **`isInsufficientBalance`**. The sign UI disables **Confirm**, shows an **Insufficient funds** danger banner, and treats that like other hard blocks (alongside failed simulation). Tests and handler/cronjob mocks wire the new flag (default `false` in the diff). > > **Tests:** `FeeCalculatorService` tests are refactored around a **`withFeeCalculatorService`** helper (typed mocks, no shared `beforeEach`) and expectations are updated for the new energy/bandwidth line items. Coverage thresholds and changelog/manifest shasum are bumped accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 0d6a7da3f7c63b3323b3c340deee57674b9d8d0f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…er for `computeStakeFee` (#366) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> - Updated tests for `ClientRequestHandler - computeStakeFee` - Followed guidelines to [avoid the usage of beforeEach](https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Test-only refactor in `clientRequest.test.ts` with no production code changes. > > **Overview** > Refactors **`ClientRequestHandler - computeStakeFee`** tests to follow unit-testing guidance by dropping a local **`beforeEach`** and wiring cases through the shared **`withClientRequestHandler`** helper used for **`onAmountInput`**. > > The helper is extended so those tests get isolated mocks without duplicating setup: typed **`MockTronWeb`** / factory helpers, a real **`tronWebFactory`** stub (including **`freezeBalanceV2`**), and extra account/asset service methods (**`findByIdOrThrow`**, **`getAssetByAccountId`**, etc.) passed into each test callback. Assertions stay the same (mainnet stake fee path and insufficient-balance short-circuit); mocks are tightened with **`AssetEntity`** and **`Transaction<FreezeBalanceV2Contract>`** instead of loose **`any`** casts, and the success case no longer sets up **`trx.sign`** because fee computation uses an unsigned transaction. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 5532a03900beff37396a68a2b0bdd3a7566e8cf4. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…er for `confirmSend validation` (#367) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> - Updated tests for `ClientRequestHandler - confirmSend validation` - Followed guidelines to [avoid the usage of beforeEach](https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a summary for commit b15e47678ecebbbaf2f31be753d45f5b6a708e31. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…er for `claimUnstakedTrx` (#368) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> - Updated tests for `ClientRequestHandler - claimUnstakedTrx` - Followed guidelines to [avoid the usage of beforeEach](https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Test-only refactor in `clientRequest.test.ts`; no production handler or staking logic changes. > > **Overview** > Refactors **`ClientRequestHandler - claimUnstakedTrx`** tests to follow MetaMask unit-testing guidance by **dropping `beforeEach`** and running each case through the shared **`withClientRequestHandler`** helper. > > The helper is extended so **`claimUnstakedTrx`** scenarios get real mocks for **`StakingService.claimUnstakedTrx`** and **`ConfirmationHandler.confirmClaimUnstakedTrx`** (instead of empty stubs). Tests now use **`ClientRequestMethod.ClaimUnstakedTrx`** and typed **`TronKeyringAccount`** fixtures; behavior under test (success, user rejection, invalid params) is unchanged. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 93a8901fc345c7837e25515fddbd9b9c18caed58. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…er for `claimTrxStakingRewards` (#369) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> - Updated tests for `ClientRequestHandler - claimTrxStakingRewards` - Followed guidelines to [avoid the usage of beforeEach](https://github.com/MetaMask/contributor-docs/blob/main/docs/testing/unit-testing.md#avoid-the-use-of-beforeeach) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [X] I've updated the test suite for new or updated code as appropriate - [X] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Test-only changes in clientRequest.test.ts; no production or runtime behavior is modified. > > **Overview** > Refactors **`ClientRequestHandler`** unit tests in `clientRequest.test.ts` to match MetaMask’s preference for explicit setup over shared **`beforeEach`** hooks. > > Introduces a shared **`TEST_ACCOUNT_ID`** and **`createMockTronKeyringAccount()`** fixture, and reuses them in **`onAmountInput`**, **`claimUnstakedTrx`**, and related suites instead of duplicating account constants and inline objects. Extends the **`withClientRequestHandler`** staking mock to include **`claimTrxStakingRewards`**. > > The **`claimTrxStakingRewards`** block is rewritten to run inside **`withClientRequestHandler`** (fresh handler and mocks per test) instead of a local **`beforeEach`** that built a handler with mostly empty services. Assertions for a successful claim and invalid params are unchanged in intent. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e3ebb9adbabeab2851d65fc2bd8155d8a95cc8cb. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This is the release candidate for version 1.32.0. --------- Co-authored-by: github-actions <github-actions@github.com>
## Summary - add shared `TRON_BLOCK_TIME` (`PT3S`) and `TRACK_TX_MAX_ATTEMPTS` (`5`) constants - schedule initial transaction-status tracking from both SendService and direct `signAndSendTransaction` requests on the three-second Tron block interval - poll cronjob tracking every three seconds for up to five attempts, preserving the existing approximately 15-second tracking window - synchronize affected accounts as a timeout fallback instead of scheduling an off-by-one extra poll - add transaction-tracking tests and update coverage thresholds - add the Snap changelog entry required by CI ## Why A newly broadcast Tron transaction cannot meaningfully change status before the next block. Aligning the initial and subsequent checks with the approximately three-second block time avoids wasteful one-second polling while preserving the previous total tracking window. Jira: [WPN-1668](https://consensyssoftware.atlassian.net/browse/WPN-1668) ## Validation - `yarn lint:fix` - full Snap Jest suite: 55 suites, 849 tests passed - production Snap build completed and manifest shasum regenerated - pre-push checks passed <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes post-send confirmation polling and timeout fallback timing, which affects when balances/transactions refresh and when finalized analytics fire, but keeps the same ~15s window and success path. > > **Overview** > **Post-broadcast transaction tracking** now polls every **3 seconds** (via shared `TRACK_TX_INTERVAL` / `PT3S`) instead of every second, with **`TRACK_TX_MAX_ATTEMPTS` set to 5** so the overall tracking window stays ~15 seconds and matches Tron’s block cadence. > > **Scheduling after send** in `SendService`, `ClientRequestHandler`, and the cron `trackTransaction` job all use these constants instead of hardcoded `PT1S` / 15 attempts. > > **`trackTransaction` behavior** is tightened: timeout handling is centralized in `#syncAccountsAfterTrackingTimeout`; when the last attempt still has no confirmation or errors, it syncs accounts without scheduling another poll or emitting `trackTransactionFinalized` (unchanged on successful confirmation). > > Adds **cron `trackTransaction` unit tests**, a **changelog** entry, **Jest coverage** threshold bumps, and an updated **manifest shasum**. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 87f310635731659bf49639f5907059bc77eccddd. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com>
This is the release candidate for version 1.33.0. --------- Co-authored-by: github-actions <github-actions@github.com> Co-authored-by: Ulisses Ferreira <ulisses@hey.com>
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> Removing some dead code depending on an hardcoded `isIncremental` variable that was always `false`. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Refactor with no intended behavior change in asset sync; only manifest shasum and coverage config aside from simplified saveMany logic. > > **Overview** > Removes the unused **`isIncremental`** flag and all helpers that only existed for an incremental asset-sync mode (`isNew`, `wasSavedWithZeroAmount`, `hasNonZeroAmount`, and the `hasChanged` filter inside **`saveMany`**). **`shouldBeInAddedList`** and **`assetsToSave`** are simplified to match the behavior that was already in effect when incremental mode was hardcoded off: full snapshot persistence and asset-list updates driven by zero-balance / disappeared-asset rules. > > Also bumps Jest **coverage thresholds** slightly and updates **`snap.manifest.json`** bundle **shasum** after the rebuild. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 7d532fc9b594075d27e3fe7f9648f0a4f384660d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Summary - persist only Trongrid chain parameters, scoped per network - store the parameters together with their maintenance-window expiry - reuse persisted parameters across Snap restarts while they remain current - refresh them after Tron's next maintenance time - leave the shared `StateCache` and `useCacheUntil` behavior unchanged ## Why Chain parameters are stable until Tron's maintenance window. Persisting this specific response avoids unnecessary refetches after Snap restarts without changing caching behavior elsewhere in the Snap. Jira: [WPN-1669](https://consensyssoftware.atlassian.net/browse/WPN-1669) ## Validation - full suite: 55 suites, 848 tests passed [WPN-1669]: https://consensyssoftware.atlassian.net/browse/WPN-1669?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
This is the release candidate for version 1.33.1. --------- Co-authored-by: github-actions <github-actions@github.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
ulissesferreira
approved these changes
Jul 23, 2026
mikesposito
approved these changes
Jul 23, 2026
Battambang
approved these changes
Jul 23, 2026
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
17 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.
Explanation
Move commits from tron wallet snap into
merged-packages/References
Related to WPN-1322
Checklist