Skip to content
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

feat: add more bridge fields to txMeta for Bridge #4918

Closed

Conversation

infiniteflower
Copy link
Contributor

@infiniteflower infiniteflower commented Nov 12, 2024

Explanation

This PR adds a number of new fields to the TransactionMeta type to facilitate Bridge transactions.

We track overall Bridge status through a new BridgeStatusController in Extension. However, that assumes that transactions have a txHash on the source chain that can be used as a reference. For smart transactions (STX), a txHash is not returned immediately. Therefore, we need to attach some additional data to the txMeta so we can properly display information about the transaction even when there is no txHash.

Even if STX returns a txHash right away, it's gated behind a feature flag, which means it can be disabled at any time so we need to have a backup in place.

References

Related to MetaMask/metamask-extension#27740, MetaMask/metamask-extension#28460

Changelog

@metamask/transaction-controller

  • ADDED: bridgeSteps, destinationChainId to the TransactionMeta type
  • ADDED: In addTransaction(), update the txMeta object through the swaps.meta field when it is a Bridge tx, similar to what happens when it's a Swap tx
  • ADDED: TransactionControllerTransactionNewBridgeApprovalEvent, TransactionControllerTransactionNewBridgeEvent events

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 highlighted breaking changes using the "BREAKING" category above as appropriate
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

@infiniteflower infiniteflower changed the title feat: add sourceChainId and destinatonChainId to txMeta feat: add more bridge fields to txMeta Nov 14, 2024
@infiniteflower infiniteflower changed the title feat: add more bridge fields to txMeta feat: add more bridge fields to txMeta for Bridge Nov 14, 2024
github-merge-queue bot pushed a commit to MetaMask/metamask-extension that referenced this pull request Nov 21, 2024
## **Description**

This PR implements the following:

1. Submit bridge transaction for normal transactions
3. Submit bridge transaction for native gas tokens that don't require
approval
4. Submit bridge transaction for ERC20s that require approval

Does not fully:
1. Submit bridge transaction for smart transactions
- You can submit an STX, but the status screens don't make the most
sense right now.
- Improved STX support be handled by
#28460 and
MetaMask/core#4918

[![Open in GitHub
Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/27262?quickstart=1)

## **Related issues**

- Targeting: #27522

## **Manual testing steps**

1. Go to Bridge
2. Fill in source/dest token and amounts
3. Get a quote
4. Execute Bridge

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**

<!-- [screenshots/recordings] -->

### **After**

<!-- [screenshots/recordings] -->


https://github.com/user-attachments/assets/b73f917d-e3e4-468b-b0fa-29f41f559488




## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.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-extension/blob/develop/.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.
@infiniteflower infiniteflower force-pushed the feat/tx-controller-bridge-source-dest-chain-ids branch from 4adbdd1 to b81c944 Compare November 22, 2024 21:15
@infiniteflower infiniteflower force-pushed the feat/tx-controller-bridge-source-dest-chain-ids branch from 5079a84 to bd9efa2 Compare November 25, 2024 16:14
@infiniteflower infiniteflower marked this pull request as ready for review November 25, 2024 16:20
@infiniteflower infiniteflower requested a review from a team as a code owner November 25, 2024 16:20
/**
* Represents the `TransactionController:transactionNewBridgeApproval` event.
*/
export type TransactionControllerTransactionNewBridgeApprovalEvent = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In an ideal world, the controller wouldn't be coupled to specific transaction types in the events since we already have the unapprovedTransactionAdded.

Could we instead just subscribe to that in the client and check the type property?

Copy link
Contributor Author

@infiniteflower infiniteflower Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes we can, I was just referencing the similar Swap types here initially.

@@ -1354,3 +1364,37 @@ export type SubmitHistoryEntry = {
export type InternalAccount = ReturnType<
AccountsController['getSelectedAccount']
>;
enum BridgeActionTypes {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, line break.

protocol: BridgeProtocol;
};

export type BridgeAsset = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JSDoc for types and all properties?

/**
*
*/
bridgeSteps?: BridgeStep[];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, do we definitely need to store this here? We don't have a bridge specific controller that will persist this state also and can link to a transaction ID?

@infiniteflower
Copy link
Contributor Author

infiniteflower commented Nov 27, 2024

@matthewwalsh0 Thank you for the insightful comments. I've decided to close this PR in favor of #4988 which only adds destintationChainId.

Figured out a way to get around the STX issues in the client that does not require all these extraneous fields being added to the TransactionController as you noted. Managed to link the transaction to the Bridge history data through the txMeta.id.

infiniteflower added a commit that referenced this pull request Nov 27, 2024
## 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 adds a new field to the `TransactionMeta` type to facilitate
Bridge transactions.

The primary purpose is to ensure that `destinationTokenAddress` refers
to the correct token on the correct chain.

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

A slimmed down version of #4918

Related to MetaMask/metamask-extension#28460

## Changelog

<!--
If you're making any consumer-facing changes, list those changes here as
if you were updating a changelog, using the template below as a guide.

(CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or
FIXED. For security-related issues, follow the Security Advisory
process.)

Please take care to name the exact pieces of the API you've added or
changed (e.g. types, interfaces, functions, or methods).

If there are any breaking changes, make sure to offer a solution for
consumers to follow once they upgrade to the changes.

Finally, if you're only making changes to development scripts or tests,
you may replace the template below with "None".
-->

### `@metamask/transaction-controller`

- **ADDED**: `destinationChainId` to the `TransactionMeta` type

## Checklist

- [ ] 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 highlighted breaking changes using the "BREAKING" category
above as appropriate
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants