Add nonce tracker to transactions controller#1147
Conversation
|
New dependency changes detected. Learn more about Socket for GitHub ↗︎ 👍 No new dependency issues detected in pull request Bot CommandsTo ignore an alert, reply with a comment starting with Pull request alert summary
📊 Modified Dependency Overview:
|
0e048e4 to
f503244
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
a96d64c to
1f288cd
Compare
|
@metamaskbot publish-preview |
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
Gudahtt
left a comment
There was a problem hiding this comment.
Great work! Left some minor comments but generally this all looks correct.
1f288cd to
58737d6
Compare
29f8fb4 to
feda1b9
Compare
feda1b9 to
f32cf8b
Compare
f32cf8b to
28a00da
Compare
28a00da to
4abd631
Compare
4abd631 to
f32cf8b
Compare
f32cf8b to
2138d65
Compare
| * @param transactions - Array of transactionMeta objects that have been prefiltered. | ||
| * @returns Array of transactions formatted for the nonce tracker. | ||
| */ | ||
| export function getAndFormatTransactionsForNonceTracker( |
There was a problem hiding this comment.
I opted to make this a utility function rather than a private method on the TransactionsController just so testing it made more sense... happy to move it to the controller if we think that makes more sense.
|
Looks great! CI is failing due to a drop in test coverage though. |
|
Ah, for those lines I'd suggest we use a real nonce tracker instead of a mock one. We can mock the provider passed into the nonce tracker instead. Then those lines will be tested as part of the tests you've already written |
| type BlockTracker = any; | ||
|
|
||
| type BlockTrackerProxy = SwappableProxy<BlockTracker>; | ||
| export type BlockTrackerProxy = SwappableProxy<BlockTracker>; |
There was a problem hiding this comment.
As this is now an exported type, doesn't it warrant constraining BlockTracker to something more specific than any?
There was a problem hiding this comment.
Perhaps! But I don't believe that's appropriately scoped to this PR. As you can see directly above this we are doing the same with Provider:
type Provider = any;
export type ProviderProxy = SwappableProxy<Provider>;
There was a problem hiding this comment.
How does the type of Provider reduce the scope of this PR?
The impacts of the type being any is different for public and private interfaces. A type which is acceptable as any internally may require constraining before being appropriate for exposure.
There was a problem hiding this comment.
How does the type of Provider reduce the scope of this PR?
On that point I was just noting that we're already exporting the ProviderProxy object with a Provider type parameter that is also typed as any.
There was a problem hiding this comment.
Currently the BlockTracker is set here, where it is a property on the Provider. I believe there is an intention to follow back here and improve typing soon. cc @Gudahtt @mcmire
If we think it makes sense to add the types for both Provider and BlockTracker in this PR I'm open to that.
There was a problem hiding this comment.
Yes, that's right. We're using any at the moment because web3-provider-engine doesn't provide types at all, and we're about to replace it anyway (see #1116). Once the replacement is complete, then we can just use the correct types from @metamask/eth-json-rpc-provider and eth-block-tracker.
| let nonceToUse = nonce; | ||
| // if a nonce already exists on the transactionMeta it means this is a speedup or cancel transaction | ||
| // so we want to reuse that nonce and hope that it beats the previous attempt to chain. Otherwise use a new locked nonce | ||
| if (!nonceToUse) { |
There was a problem hiding this comment.
@Gudahtt I'm realizing that this isn't actually necessary in the current implementation since in this TransactionController we don't actually re-process/re-approve speedup and cancel transactions in this method as we do in the extension TransactionController. Rather we just modify the transaction and re-broadcast it directly in the speedup/cancel method, for instance here.
That said it may make sense to leave this logic to ensure correct nonce management in future uses of this method. And as it is currently there is no issue keeping this logic since nonceToUse should always be undefined on line 680.
a913cf4 to
c2961a4
Compare
* add nonceTracker to TransactionsController
* add nonceTracker to TransactionsController

Resolves: #1070
NonceTrackerpackage to transaction approval flow to manage transaction nonces. This functionality was previously handled by middleware in `web3-provider-engine which is slated to be removed. #123