1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-12-01 21:57:06 +01:00
metamask-extension/app/scripts/controllers/transactions/tx-state-manager.test.js

1365 lines
43 KiB
JavaScript
Raw Normal View History

import { strict as assert } from 'assert';
import sinon from 'sinon';
import {
TransactionStatus,
TransactionType,
} from '../../../../shared/constants/transaction';
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
import {
CHAIN_IDS,
NETWORK_IDS,
NetworkStatus,
} from '../../../../shared/constants/network';
2021-06-29 22:08:16 +02:00
import { GAS_LIMITS } from '../../../../shared/constants/gas';
import { ORIGIN_METAMASK } from '../../../../shared/constants/app';
import TxStateManager, { ERROR_SUBMITTING } from './tx-state-manager';
import { snapshotFromTxMeta } from './lib/tx-state-history-helpers';
const VALID_ADDRESS = '0x0000000000000000000000000000000000000000';
const VALID_ADDRESS_TWO = '0x0000000000000000000000000000000000000001';
function generateTransactions(
numToGen,
{
chainId,
to,
from,
status,
type = TransactionType.simpleSend,
nonce = (i) => `${i}`,
},
) {
const txs = [];
for (let i = 0; i < numToGen; i++) {
const tx = {
id: i,
time: new Date() * i,
status: typeof status === 'function' ? status(i) : status,
chainId: typeof chainId === 'function' ? chainId(i) : chainId,
txParams: {
nonce: nonce(i),
to,
from,
},
type: typeof type === 'function' ? type(i) : type,
};
txs.push(tx);
}
return txs;
}
2018-03-07 19:24:36 +01:00
describe('TransactionStateManager', function () {
let txStateManager;
const currentNetworkId = NETWORK_IDS.GOERLI;
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
const currentNetworkStatus = NetworkStatus.Available;
const currentChainId = CHAIN_IDS.MAINNET;
const otherNetworkId = '2';
2017-08-11 23:19:35 +02:00
beforeEach(function () {
txStateManager = new TxStateManager({
initState: {
transactions: {},
2017-08-11 23:19:35 +02:00
},
txHistoryLimit: 10,
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
getNetworkId: () => currentNetworkId,
getNetworkStatus: () => currentNetworkStatus,
getCurrentChainId: () => currentChainId,
});
});
2017-08-11 23:19:35 +02:00
describe('#setTxStatusSigned', function () {
it('sets the tx status to signed', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
txStateManager.addTransaction(tx);
txStateManager.setTxStatusSigned(1);
const result = txStateManager.getTransactions();
assert.ok(Array.isArray(result));
assert.equal(result.length, 1);
assert.equal(result[0].status, TransactionStatus.signed);
});
2017-08-11 23:19:35 +02:00
it('should emit a signed event to signal the execution of callback', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
const clock = sinon.useFakeTimers();
const onSigned = sinon.spy();
txStateManager.addTransaction(tx);
txStateManager.on('1:signed', onSigned);
txStateManager.setTxStatusSigned(1);
clock.runAll();
clock.restore();
2017-08-11 23:19:35 +02:00
assert.ok(onSigned.calledOnce);
});
});
2017-08-11 23:19:35 +02:00
describe('#setTxStatusRejected', function () {
it('sets the tx status to rejected and removes it from history', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
txStateManager.addTransaction(tx);
txStateManager.setTxStatusRejected(1);
const result = txStateManager.getTransactions();
assert.ok(Array.isArray(result));
assert.equal(result.length, 0);
});
it('should emit a rejected event to signal the execution of callback', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
const clock = sinon.useFakeTimers();
const onSigned = sinon.spy();
txStateManager.addTransaction(tx);
txStateManager.on('1:rejected', onSigned);
txStateManager.setTxStatusRejected(1);
clock.runAll();
clock.restore();
assert.ok(onSigned.calledOnce);
});
});
2017-08-11 23:19:35 +02:00
describe('#getTransactions', function () {
2017-08-11 23:19:35 +02:00
it('when new should return empty array', function () {
const result = txStateManager.getTransactions();
assert.ok(Array.isArray(result));
assert.equal(result.length, 0);
});
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
it('should return a full list of transactions', function () {
const submittedTx = {
id: 0,
metamaskNetworkId: currentNetworkId,
time: 0,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x0',
},
status: TransactionStatus.submitted,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const confirmedTx = {
id: 3,
metamaskNetworkId: currentNetworkId,
time: 3,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x3',
},
status: TransactionStatus.confirmed,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const txm = new TxStateManager({
initState: {
transactions: {
[submittedTx.id]: submittedTx,
[confirmedTx.id]: confirmedTx,
},
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
},
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
getNetworkId: () => currentNetworkId,
getNetworkStatus: () => currentNetworkStatus,
getCurrentChainId: () => currentChainId,
});
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
assert.deepEqual(txm.getTransactions(), [submittedTx, confirmedTx]);
});
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
it('should return a list of transactions, limited by N unique nonces when there are NO duplicates', function () {
const submittedTx0 = {
id: 0,
metamaskNetworkId: currentNetworkId,
time: 0,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x0',
},
status: TransactionStatus.submitted,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const unapprovedTx1 = {
id: 1,
metamaskNetworkId: currentNetworkId,
time: 1,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x1',
},
status: TransactionStatus.unapproved,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const approvedTx2 = {
id: 2,
metamaskNetworkId: currentNetworkId,
time: 2,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x2',
},
status: TransactionStatus.approved,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const confirmedTx3 = {
id: 3,
metamaskNetworkId: currentNetworkId,
time: 3,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x3',
},
status: TransactionStatus.confirmed,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const txm = new TxStateManager({
initState: {
transactions: {
[submittedTx0.id]: submittedTx0,
[unapprovedTx1.id]: unapprovedTx1,
[approvedTx2.id]: approvedTx2,
[confirmedTx3.id]: confirmedTx3,
},
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
},
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
getNetworkId: () => currentNetworkId,
getNetworkStatus: () => currentNetworkStatus,
getCurrentChainId: () => currentChainId,
});
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
assert.deepEqual(txm.getTransactions({ limit: 2 }), [
approvedTx2,
confirmedTx3,
]);
});
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
it('should return a list of transactions, limited by N unique nonces when there ARE duplicates', function () {
const submittedTx0 = {
id: 0,
metamaskNetworkId: currentNetworkId,
time: 0,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x0',
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
},
status: TransactionStatus.submitted,
};
const submittedTx0Dupe = {
id: 1,
metamaskNetworkId: currentNetworkId,
time: 0,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x0',
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
},
status: TransactionStatus.submitted,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const unapprovedTx1 = {
id: 2,
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
metamaskNetworkId: currentNetworkId,
chainId: currentChainId,
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
time: 1,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x1',
},
status: TransactionStatus.unapproved,
};
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
const approvedTx2 = {
id: 3,
metamaskNetworkId: currentNetworkId,
time: 2,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x2',
},
status: TransactionStatus.approved,
};
const approvedTx2Dupe = {
id: 4,
metamaskNetworkId: currentNetworkId,
chainId: currentChainId,
time: 2,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x2',
},
status: TransactionStatus.approved,
};
const failedTx3 = {
id: 5,
metamaskNetworkId: currentNetworkId,
time: 3,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x3',
},
status: TransactionStatus.failed,
};
const failedTx3Dupe = {
id: 6,
metamaskNetworkId: currentNetworkId,
chainId: currentChainId,
time: 3,
txParams: {
from: '0xAddress',
to: '0xRecipient',
nonce: '0x3',
},
status: TransactionStatus.failed,
};
const txm = new TxStateManager({
initState: {
transactions: {
[submittedTx0.id]: submittedTx0,
[submittedTx0Dupe.id]: submittedTx0Dupe,
[unapprovedTx1.id]: unapprovedTx1,
[approvedTx2.id]: approvedTx2,
[approvedTx2Dupe.id]: approvedTx2Dupe,
[failedTx3.id]: failedTx3,
[failedTx3Dupe.id]: failedTx3Dupe,
},
},
NetworkController: Split `network` into `networkId` and `networkStatus` (#17556) The `network` store of the network controller crams two types of data into one place. It roughly tracks whether we have enough information to make requests to the network and whether the network is capable of receiving requests, but it also stores the ID of the network (as obtained via `net_version`). Generally we shouldn't be using the network ID for anything, as it has been completely replaced by chain ID, which all custom RPC endpoints have been required to support for over a year now. However, as the network ID is used in various places within the extension codebase, removing it entirely would be a non-trivial effort. So, minimally, this commit splits `network` into two stores: `networkId` and `networkStatus`. But it also expands the concept of network status. Previously, the network was in one of two states: "loading" and "not-loading". But now it can be in one of four states: - `available`: The network is able to receive and respond to requests. - `unavailable`: The network is not able to receive and respond to requests for unknown reasons. - `blocked`: The network is actively blocking requests based on the user's geolocation. (This is specific to Infura.) - `unknown`: We don't know whether the network can receive and respond to requests, either because we haven't checked or we tried to check and were unsuccessful. This commit also changes how the network status is determined — specifically, how many requests are used to determine that status, when they occur, and whether they are awaited. Previously, the network controller would make 2 to 3 requests during the course of running `lookupNetwork`. * First, if it was an Infura network, it would make a request for `eth_blockNumber` to determine whether Infura was blocking requests or not, then emit an appropriate event. This operation was not awaited. * Then, regardless of the network, it would fetch the network ID via `net_version`. This operation was awaited. * Finally, regardless of the network, it would fetch the latest block via `eth_getBlockByNumber`, then use the result to determine whether the network supported EIP-1559. This operation was awaited. Now: * One fewer request is made, specifically `eth_blockNumber`, as we don't need to make an extra request to determine whether Infura is blocking requests; we can reuse `eth_getBlockByNumber`; * All requests are awaited, which makes `lookupNetwork` run fully in-band instead of partially out-of-band; and * Both requests for `net_version` and `eth_getBlockByNumber` are performed in parallel to make `lookupNetwork` run slightly faster.
2023-03-31 00:49:12 +02:00
getNetworkId: () => currentNetworkId,
getNetworkStatus: () => currentNetworkStatus,
getCurrentChainId: () => currentChainId,
});
assert.deepEqual(txm.getTransactions({ limit: 2 }), [
approvedTx2,
approvedTx2Dupe,
failedTx3,
failedTx3Dupe,
]);
});
it('returns a tx with the requested data', function () {
const txMetas = [
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
{
id: 0,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
metamaskNetworkId: currentNetworkId,
},
{
id: 1,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
metamaskNetworkId: currentNetworkId,
},
{
id: 2,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
metamaskNetworkId: currentNetworkId,
},
{
id: 3,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS_TWO, to: VALID_ADDRESS },
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
metamaskNetworkId: currentNetworkId,
},
{
id: 4,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS_TWO, to: VALID_ADDRESS },
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
metamaskNetworkId: currentNetworkId,
},
{
id: 5,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
metamaskNetworkId: currentNetworkId,
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
},
{
id: 6,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
metamaskNetworkId: currentNetworkId,
},
{
id: 7,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS_TWO, to: VALID_ADDRESS },
metamaskNetworkId: currentNetworkId,
},
{
id: 8,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS_TWO, to: VALID_ADDRESS },
metamaskNetworkId: currentNetworkId,
},
{
id: 9,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS_TWO, to: VALID_ADDRESS },
metamaskNetworkId: currentNetworkId,
},
];
txMetas.forEach((txMeta) => txStateManager.addTransaction(txMeta));
let searchCriteria;
Limit number of transactions passed outside of TransactionController (#9010) Refs #8572 Refs #8991 This change limits the number of transactions (`txMeta`s) that are passed outside of the `TransactionController`, resulting in shorter serialization and deserialization times when state is moved between the background and UI contexts. `TransactionController#_updateMemstore` --------------------------------------- The `currentNetworkTxList` state of the `TransactionController` is used externally (i.e. outside of the controller) as the canonical source for the full transaction history. Prior to this change, the method would iterate the full transaction history and possibly return all of it. This change limits it to `MAX_MEMSTORE_TX_LIST_SIZE` to make sure that: 1. Calls to `_updateMemstore` are fast(er) 2. Passing `currentNetworkTxList` around is fast(er) (Shown in #8377, `_updateMemstore`, is called _frequently_ when a transaction is pending.) The list is iterated backwards because it is possible that new transactions are at the end of the list. [1] Results ------- In profiles before this change, with ~3k transactions locally, `PortDuplexStream._onMessage` took up to ~4.5s to complete when the set of transactions is included. [2] In profiles after this change, `PortDuplexStream._onMessage` took ~90ms to complete. [3] Before vs. after profile screenshots: ![Profile 1][2] ![Profile 2][3] [1]:https://github.com/MetaMask/metamask-extension/blob/5a3ae85b728096cb45c8cc6822249eed5555ee25/app/scripts/controllers/transactions/tx-state-manager.js#L172-L174 [2]:https://user-images.githubusercontent.com/1623628/87613203-36f51d80-c6e7-11ea-89bc-11a1cc2f3b1e.png [3]:https://user-images.githubusercontent.com/1623628/87613215-3bb9d180-c6e7-11ea-8d85-aff3acbd0374.png [8337]:https://github.com/MetaMask/metamask-extension/issues/8377 [8572]:https://github.com/MetaMask/metamask-extension/issues/8572 [8991]:https://github.com/MetaMask/metamask-extension/issues/8991
2020-07-16 22:22:41 +02:00
searchCriteria = {
status: TransactionStatus.unapproved,
from: VALID_ADDRESS,
};
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
3,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = {
status: TransactionStatus.unapproved,
to: VALID_ADDRESS,
};
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
2,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = {
status: TransactionStatus.confirmed,
from: VALID_ADDRESS_TWO,
};
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
3,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = { status: TransactionStatus.confirmed };
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
5,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = { from: VALID_ADDRESS };
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
5,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = { to: VALID_ADDRESS };
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
5,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
searchCriteria = {
status: (status) => status !== TransactionStatus.confirmed,
};
assert.equal(
txStateManager.getTransactions({ searchCriteria }).length,
5,
`getTransactions - ${JSON.stringify(searchCriteria)}`,
);
});
});
2017-08-11 23:19:35 +02:00
describe('#addTransaction', function () {
it('adds a tx returned in getTransactions', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
txStateManager.addTransaction(tx);
const result = txStateManager.getTransactions();
assert.ok(Array.isArray(result));
assert.equal(result.length, 1);
assert.equal(result[0].id, 1);
});
2017-08-11 23:19:35 +02:00
it('throws error and does not add tx if txParams are invalid', function () {
const validTxParams = {
from: '0x0dcd5d886577d5081b0c52e242ef29e70be3e7bc',
to: '0x0039f22efb07a647557c7c5d17854cfd6d489ef3',
nonce: '0x3',
gas: '0x77359400',
gasPrice: '0x77359400',
value: '0x0',
data: '0x0',
};
const invalidValues = [1, true, {}, Symbol('1')];
2020-07-21 23:10:45 +02:00
Object.keys(validTxParams).forEach((key) => {
for (const value of invalidValues) {
const tx = {
id: 1,
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
...validTxParams,
[key]: value,
},
};
2020-11-03 00:41:28 +01:00
assert.throws(
txStateManager.addTransaction.bind(txStateManager, tx),
'addTransaction should throw error',
);
const result = txStateManager.getTransactions();
assert.ok(Array.isArray(result), 'txList should be an array');
assert.equal(result.length, 0, 'txList should be empty');
}
});
});
2017-08-11 23:19:35 +02:00
it('does not override txs from other networks', function () {
2020-11-03 00:41:28 +01:00
const tx = {
id: 1,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
2020-11-03 00:41:28 +01:00
const tx2 = {
id: 2,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: otherNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
},
};
txStateManager.addTransaction(tx);
txStateManager.addTransaction(tx2);
const result = txStateManager.getTransactions({
filterToCurrentNetwork: false,
});
const result2 = txStateManager.getTransactions();
assert.equal(result.length, 2, 'txs were deleted');
assert.equal(result2.length, 1, 'incorrect number of txs on network.');
});
2017-08-11 23:19:35 +02:00
it('cuts off early txs beyond a limit', function () {
const limit = txStateManager.txHistoryLimit;
const txs = generateTransactions(limit + 1, {
chainId: currentChainId,
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
status: TransactionStatus.confirmed,
});
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions();
assert.equal(result.length, limit, `limit of ${limit} txs enforced`);
assert.equal(result[0].id, 1, 'early txs truncated');
});
2017-08-11 23:19:35 +02:00
it('cuts off early txs beyond a limit whether or not it is confirmed or rejected', function () {
const limit = txStateManager.txHistoryLimit;
const txs = generateTransactions(limit + 1, {
chainId: currentChainId,
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
status: TransactionStatus.rejected,
});
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions();
assert.equal(result.length, limit, `limit of ${limit} txs enforced`);
assert.equal(result[0].id, 1, 'early txs truncated');
});
2017-08-11 23:19:35 +02:00
it('cuts off early txs beyond a limit but does not cut unapproved txs', function () {
const limit = txStateManager.txHistoryLimit;
const txs = generateTransactions(
// we add two transactions over limit here to first insert the must be always present
// unapproved tx, then another to force the original logic of adding
// one more beyond the first additional.
limit + 2,
{
chainId: currentChainId,
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
status: (i) =>
i === 0
? TransactionStatus.unapproved
: TransactionStatus.confirmed,
},
);
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions();
assert.equal(
result.length,
limit + 1,
`limit of ${limit} + 1 for the unapproved tx is enforced`,
);
assert.equal(result[0].id, 0, 'first tx should still be there');
2020-11-03 00:41:28 +01:00
assert.equal(
result[0].status,
TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
'first tx should be unapproved',
);
assert.equal(result[1].id, 2, 'early txs truncated');
});
it('cuts off entire groups of transactions by nonce when adding new transaction', function () {
const limit = txStateManager.txHistoryLimit;
// In this test case the earliest two transactions are a dropped attempted ether send and a
// following cancel transaction with the same nonce. these two transactions should be dropped
// together as soon as the 11th unique nonce is attempted to be added. We use limit + 2 to
// first get into the state where we are over the "limit" of transactions because of a set
// of transactions with a unique nonce/network combo, then add an additional new transaction
// to trigger the removal of one group of nonces.
const txs = generateTransactions(limit + 2, {
chainId: currentChainId,
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
nonce: (i) => (i === 1 ? `0` : `${i}`),
status: (i) =>
i === 0 ? TransactionStatus.dropped : TransactionStatus.confirmed,
type: (i) =>
i === 1 ? TransactionType.cancel : TransactionType.simpleSend,
});
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions();
assert.equal(result.length, limit, `limit of ${limit} is enforced`);
assert.notEqual(result[0].id, 0, 'first tx should be removed');
assert.equal(
result.some(
(tx) =>
tx.status === TransactionStatus.dropped ||
tx.status === TransactionType.cancel,
),
false,
'the cancel and dropped transactions should not be present in the result',
);
});
it('cuts off entire groups of transactions by nonce + network when adding new transaction', function () {
const limit = txStateManager.txHistoryLimit;
// In this test case the earliest two transactions are a dropped attempted ether send and a
// following cancel transaction with the same nonce. Then, a bit later the same scenario on a
// different network. The first two transactions should be dropped after adding even another
// single transaction but the other shouldn't be dropped until adding the fifth additional
// transaction
const txs = generateTransactions(limit + 5, {
chainId: (i) => {
if (i === 0 || i === 1) {
return CHAIN_IDS.MAINNET;
} else if (i === 4 || i === 5) {
return CHAIN_IDS.GOERLI;
}
return currentChainId;
},
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
nonce: (i) => ([0, 1, 4, 5].includes(i) ? '0' : `${i}`),
status: (i) =>
i === 0 || i === 4
? TransactionStatus.dropped
: TransactionStatus.confirmed,
type: (i) =>
i === 1 || i === 5
? TransactionType.cancel
: TransactionType.simpleSend,
});
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions({
filterToCurrentNetwork: false,
});
assert.equal(
result.length,
limit + 1,
`limit of ${limit} + 1 for the grouped transactions is enforced`,
);
// The first group of transactions on mainnet should be removed
assert.equal(
result.some(
(tx) =>
tx.chainId === CHAIN_IDS.MAINNET && tx.txParams.nonce === '0x0',
),
false,
'the mainnet transactions with nonce 0x0 should not be present in the result',
);
});
it('does not cut off entire groups of transactions when adding new transaction when under limit', function () {
// In this test case the earliest two transactions are a dropped attempted ether send and a
// following cancel transaction with the same nonce. Then, a bit later the same scenario on a
// different network. None of these should be dropped because we haven't yet reached the limit
const limit = txStateManager.txHistoryLimit;
const txs = generateTransactions(limit - 1, {
chainId: (i) => ([0, 1, 4, 5].includes(i) ? currentChainId : '0x1'),
to: VALID_ADDRESS,
from: VALID_ADDRESS_TWO,
nonce: (i) => {
if (i === 1) {
return '0';
} else if (i === 5) {
return '4';
}
return `${i}`;
},
status: (i) =>
i === 0 || i === 4
? TransactionStatus.dropped
: TransactionStatus.confirmed,
type: (i) =>
i === 1 || i === 5
? TransactionType.cancel
: TransactionType.simpleSend,
});
txs.forEach((tx) => txStateManager.addTransaction(tx));
const result = txStateManager.getTransactions({
filterToCurrentNetwork: false,
});
assert.equal(result.length, 9, `all nine transactions should be present`);
assert.equal(result[0].id, 0, 'first tx should be present');
});
});
2017-08-11 23:19:35 +02:00
describe('#updateTransaction', function () {
2017-08-11 23:19:35 +02:00
it('replaces the tx with the same id', function () {
txStateManager.addTransaction({
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
txStateManager.addTransaction({
id: '2',
status: TransactionStatus.confirmed,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
const txMeta = txStateManager.getTransaction('1');
txMeta.hash = 'foo';
txStateManager.updateTransaction(txMeta);
const result = txStateManager.getTransaction('1');
assert.equal(result.hash, 'foo');
});
2017-08-11 23:19:35 +02:00
it('throws error and does not update tx if txParams are invalid', function () {
const validTxParams = {
from: '0x0dcd5d886577d5081b0c52e242ef29e70be3e7bc',
to: '0x0039f22efb07a647557c7c5d17854cfd6d489ef3',
nonce: '0x3',
gas: '0x77359400',
gasPrice: '0x77359400',
value: '0x0',
data: '0x0',
};
const invalidValues = [1, true, {}, Symbol('1')];
txStateManager.addTransaction({
2020-11-03 00:41:28 +01:00
id: 1,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
txParams: validTxParams,
});
2020-07-21 23:10:45 +02:00
Object.keys(validTxParams).forEach((key) => {
for (const value of invalidValues) {
const originalTx = txStateManager.getTransaction(1);
const newTx = {
...originalTx,
txParams: {
...originalTx.txParams,
[key]: value,
},
};
2020-11-03 00:41:28 +01:00
assert.throws(
txStateManager.updateTransaction.bind(txStateManager, newTx),
'updateTransaction should throw an error',
);
const result = txStateManager.getTransaction(1);
assert.deepEqual(result, originalTx, 'tx should not be updated');
}
});
});
it('updates gas price and adds history items', function () {
const originalGasPrice = '0x01';
const desiredGasPrice = '0x02';
2017-08-11 23:19:35 +02:00
const txMeta = {
id: '1',
status: TransactionStatus.unapproved,
2017-08-11 23:19:35 +02:00
metamaskNetworkId: currentNetworkId,
txParams: {
from: VALID_ADDRESS_TWO,
to: VALID_ADDRESS,
2017-08-11 23:19:35 +02:00
gasPrice: originalGasPrice,
},
};
2017-08-11 23:19:35 +02:00
txStateManager.addTransaction(txMeta);
const updatedTx = txStateManager.getTransaction('1');
// verify tx was initialized correctly
assert.equal(updatedTx.history.length, 1, 'one history item (initial)');
2020-11-03 00:41:28 +01:00
assert.equal(
Array.isArray(updatedTx.history[0]),
false,
'first history item is initial state',
);
2020-11-03 00:41:28 +01:00
assert.deepEqual(
updatedTx.history[0],
snapshotFromTxMeta(updatedTx),
'first history item is initial state',
);
// modify value and updateTransaction
updatedTx.txParams.gasPrice = desiredGasPrice;
const timeBefore = new Date().getTime();
txStateManager.updateTransaction(updatedTx);
const timeAfter = new Date().getTime();
// check updated value
const result = txStateManager.getTransaction('1');
2020-11-03 00:41:28 +01:00
assert.equal(
result.txParams.gasPrice,
desiredGasPrice,
'gas price updated',
);
// validate history was updated
2020-11-03 00:41:28 +01:00
assert.equal(
result.history.length,
2,
'two history items (initial + diff)',
);
2020-11-03 00:41:28 +01:00
assert.equal(
result.history[1].length,
1,
'two history state items (initial + diff)',
);
2020-11-03 00:41:28 +01:00
const expectedEntry = {
op: 'replace',
path: '/txParams/gasPrice',
value: desiredGasPrice,
};
2020-11-03 00:41:28 +01:00
assert.deepEqual(
result.history[1][0].op,
expectedEntry.op,
'two history items (initial + diff) operation',
);
2020-11-03 00:41:28 +01:00
assert.deepEqual(
result.history[1][0].path,
expectedEntry.path,
'two history items (initial + diff) path',
);
2020-11-03 00:41:28 +01:00
assert.deepEqual(
result.history[1][0].value,
expectedEntry.value,
'two history items (initial + diff) value',
);
2020-11-03 00:41:28 +01:00
assert.ok(
result.history[1][0].timestamp >= timeBefore &&
result.history[1][0].timestamp <= timeAfter,
);
});
it('does NOT add empty history items', function () {
const txMeta = {
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
from: VALID_ADDRESS_TWO,
to: VALID_ADDRESS,
gasPrice: '0x01',
},
};
txStateManager.addTransaction(txMeta);
txStateManager.updateTransaction(txMeta);
const { history } = txStateManager.getTransaction('1');
assert.equal(history.length, 1, 'two history items (initial + diff)');
});
it('should set tx status to failed if updating after error submitting', function () {
const txMeta = {
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
from: VALID_ADDRESS_TWO,
to: VALID_ADDRESS,
gasLimit: '0x5028',
maxFeePerGas: '0x2540be400',
maxPriorityFeePerGas: '0x3b9aca00',
},
};
txStateManager.addTransaction(txMeta);
const { history } = txStateManager.getTransaction('1');
assert.equal(history.length, 1);
txMeta.txParams.type = '0x0';
txMeta.warning = {
message: ERROR_SUBMITTING,
error: 'Testing tx status failed with arbitrary error',
};
// should result in additional 2 history entries
txStateManager.updateTransaction(txMeta);
const result = txStateManager.getTransaction('1');
assert.equal(result.history.length, 3);
// history[1] should contain 3 entries
assert.equal(result.history[1].length, 3);
assert.equal(
result.history[1][0].note,
'transactions:tx-state-manager#fail - add error',
);
assert.equal(result.history[1][0].op, 'add');
assert.equal(result.history[1][0].path, '/txParams/type');
assert.equal(result.history[1][0].value, '0x0');
assert.equal(result.history[1][1].op, 'add');
assert.equal(result.history[1][1].path, '/warning');
assert.equal(result.history[1][1].value.message, ERROR_SUBMITTING);
assert.equal(result.history[1][2].op, 'add');
assert.equal(result.history[1][2].path, '/err');
assert.equal(
result.history[1][2].value.message,
'Invalid transaction envelope type: specified type "0x0" but including maxFeePerGas and maxPriorityFeePerGas requires type: "0x2"',
);
assert.equal(result.history[2].length, 1);
assert.equal(
result.history[2][0].note,
'txStateManager: setting status to failed',
);
assert.equal(result.history[2][0].op, 'replace');
assert.equal(result.history[2][0].path, '/status');
assert.equal(result.history[2][0].value, 'failed');
});
it('should set transaction status to failed', function () {
const txMeta = {
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
from: VALID_ADDRESS_TWO,
to: VALID_ADDRESS,
gasPrice: '0x01',
},
};
txStateManager.addTransaction(txMeta);
const { history } = txStateManager.getTransaction('1');
assert.equal(history.length, 1);
// should result in additional 2 history entries
txStateManager.setTxStatusFailed(
txMeta.id,
new Error('Testing tx status failed with arbitrary error'),
);
const result = txStateManager.getTransaction('1');
assert.equal(result.history.length, 3);
assert.equal(
result.history[1][0].note,
'transactions:tx-state-manager#fail - add error',
);
assert.equal(result.history[1][0].op, 'add');
assert.equal(result.history[1][0].path, '/err');
assert.equal(
result.history[1][0].value.message,
'Testing tx status failed with arbitrary error',
);
assert.equal(result.history[2].length, 1);
assert.equal(
result.history[2][0].note,
'txStateManager: setting status to failed',
);
assert.equal(result.history[2][0].op, 'replace');
assert.equal(result.history[2][0].path, '/status');
assert.equal(result.history[2][0].value, 'failed');
});
});
2017-08-11 23:19:35 +02:00
describe('#getUnapprovedTxList', function () {
it('returns unapproved txs in a hash', function () {
txStateManager.addTransaction({
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
txStateManager.addTransaction({
id: '2',
status: TransactionStatus.confirmed,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
const result = txStateManager.getUnapprovedTxList();
assert.equal(typeof result, 'object');
assert.equal(result['1'].status, TransactionStatus.unapproved);
assert.equal(result['2'], undefined);
});
});
2017-08-11 23:19:35 +02:00
describe('#getTransaction', function () {
2017-08-11 23:19:35 +02:00
it('returns a tx with the requested id', function () {
txStateManager.addTransaction({
id: '1',
status: TransactionStatus.unapproved,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
txStateManager.addTransaction({
id: '2',
status: TransactionStatus.confirmed,
metamaskNetworkId: currentNetworkId,
txParams: {
to: VALID_ADDRESS,
from: VALID_ADDRESS,
2020-11-03 00:41:28 +01:00
},
});
assert.equal(
txStateManager.getTransaction('1').status,
TransactionStatus.unapproved,
);
assert.equal(
txStateManager.getTransaction('2').status,
TransactionStatus.confirmed,
);
});
});
2017-08-11 23:19:35 +02:00
2018-01-31 19:29:30 +01:00
describe('#wipeTransactions', function () {
const specificAddress = VALID_ADDRESS;
const otherAddress = VALID_ADDRESS_TWO;
2018-01-31 19:29:30 +01:00
it('should remove only the transactions from a specific address', function () {
const txMetas = [
2020-11-03 00:41:28 +01:00
{
id: 0,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
txParams: { from: specificAddress, to: otherAddress },
metamaskNetworkId: currentNetworkId,
},
{
id: 1,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
txParams: { from: otherAddress, to: specificAddress },
metamaskNetworkId: currentNetworkId,
},
{
id: 2,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
txParams: { from: otherAddress, to: specificAddress },
metamaskNetworkId: currentNetworkId,
},
];
txMetas.forEach((txMeta) => txStateManager.addTransaction(txMeta));
2018-01-31 19:29:30 +01:00
txStateManager.wipeTransactions(specificAddress);
2018-01-31 19:29:30 +01:00
2020-11-03 00:41:28 +01:00
const transactionsFromCurrentAddress = txStateManager
.getTransactions()
.filter((txMeta) => txMeta.txParams.from === specificAddress);
2020-11-03 00:41:28 +01:00
const transactionsFromOtherAddresses = txStateManager
.getTransactions()
.filter((txMeta) => txMeta.txParams.from !== specificAddress);
2018-01-31 19:29:30 +01:00
assert.equal(transactionsFromCurrentAddress.length, 0);
assert.equal(transactionsFromOtherAddresses.length, 2);
});
2018-01-31 19:29:30 +01:00
it('should not remove the transactions from other networks', function () {
const txMetas = [
2020-11-03 00:41:28 +01:00
{
id: 0,
status: TransactionStatus.unapproved,
2020-11-03 00:41:28 +01:00
txParams: { from: specificAddress, to: otherAddress },
metamaskNetworkId: currentNetworkId,
},
{
id: 1,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
txParams: { from: specificAddress, to: otherAddress },
metamaskNetworkId: otherNetworkId,
},
{
id: 2,
status: TransactionStatus.confirmed,
2020-11-03 00:41:28 +01:00
txParams: { from: specificAddress, to: otherAddress },
metamaskNetworkId: otherNetworkId,
},
];
txMetas.forEach((txMeta) => txStateManager.addTransaction(txMeta));
2018-01-31 19:29:30 +01:00
txStateManager.wipeTransactions(specificAddress);
2018-01-31 19:29:30 +01:00
2020-11-03 00:41:28 +01:00
const txsFromCurrentNetworkAndAddress = txStateManager
.getTransactions()
.filter((txMeta) => txMeta.txParams.from === specificAddress);
2020-11-03 00:41:28 +01:00
const txFromOtherNetworks = txStateManager
.getTransactions({ filterToCurrentNetwork: false })
.filter((txMeta) => txMeta.metamaskNetworkId === otherNetworkId);
2018-01-31 19:29:30 +01:00
assert.equal(txsFromCurrentNetworkAndAddress.length, 0);
assert.equal(txFromOtherNetworks.length, 2);
});
});
describe('#_deleteTransaction', function () {
it('should remove the transaction from the storage', function () {
txStateManager.addTransaction({ id: 1 });
txStateManager._deleteTransaction(1);
2020-11-03 00:41:28 +01:00
assert.ok(
!txStateManager.getTransactions({ filterToCurrentNetwork: false })
.length,
2020-11-03 00:41:28 +01:00
'txList should be empty',
);
});
it('should only remove the transaction with ID 1 from the storage', function () {
txStateManager.store.updateState({
transactions: { 1: { id: 1 }, 2: { id: 2 } },
});
txStateManager._deleteTransaction(1);
2020-11-03 00:41:28 +01:00
assert.equal(
txStateManager.getTransactions({
filterToCurrentNetwork: false,
})[0].id,
2020-11-03 00:41:28 +01:00
2,
'txList should have a id of 2',
);
});
});
2021-06-29 22:08:16 +02:00
describe('#generateTxMeta', function () {
it('generates a txMeta object when supplied no parameters', function () {
// There are currently not safety checks for missing 'opts' but we should
// at least enforce txParams. This is done in the transaction controller
// before *calling* this method, but we should perhaps ensure that
// txParams is provided and validated in this method.
// TODO: this test should fail.
const generatedTransaction = txStateManager.generateTxMeta();
assert.ok(generatedTransaction);
});
it('generates a txMeta object with txParams specified', function () {
const txParams = {
gas: GAS_LIMITS.SIMPLE,
from: '0x0000',
to: '0x000',
value: '0x0',
gasPrice: '0x0',
};
const generatedTransaction = txStateManager.generateTxMeta({
txParams,
});
assert.ok(generatedTransaction);
assert.strictEqual(generatedTransaction.txParams, txParams);
});
it('generates a txMeta object with txParams specified using EIP-1559 fields', function () {
const txParams = {
gas: GAS_LIMITS.SIMPLE,
from: '0x0000',
to: '0x000',
value: '0x0',
maxFeePerGas: '0x0',
maxPriorityFeePerGas: '0x0',
};
const generatedTransaction = txStateManager.generateTxMeta({
txParams,
});
assert.ok(generatedTransaction);
assert.strictEqual(generatedTransaction.txParams, txParams);
});
it('records dappSuggestedGasFees when origin is provided and is not "metamask"', function () {
const eip1559GasFeeFields = {
maxFeePerGas: '0x0',
maxPriorityFeePerGas: '0x0',
gas: GAS_LIMITS.SIMPLE,
};
const legacyGasFeeFields = {
gasPrice: '0x0',
gas: GAS_LIMITS.SIMPLE,
};
const eip1559TxParams = {
from: '0x0000',
to: '0x000',
value: '0x0',
...eip1559GasFeeFields,
};
const legacyTxParams = {
from: '0x0000',
to: '0x000',
value: '0x0',
...legacyGasFeeFields,
};
const eip1559GeneratedTransaction = txStateManager.generateTxMeta({
txParams: eip1559TxParams,
origin: 'adappt.com',
});
const legacyGeneratedTransaction = txStateManager.generateTxMeta({
txParams: legacyTxParams,
origin: 'adappt.com',
});
assert.ok(
eip1559GeneratedTransaction,
'generated EIP1559 transaction should be truthy',
);
assert.deepStrictEqual(
eip1559GeneratedTransaction.dappSuggestedGasFees,
eip1559GasFeeFields,
'generated EIP1559 transaction should have appropriate dappSuggestedGasFees',
);
assert.ok(
legacyGeneratedTransaction,
'generated legacy transaction should be truthy',
);
assert.deepStrictEqual(
legacyGeneratedTransaction.dappSuggestedGasFees,
legacyGasFeeFields,
'generated legacy transaction should have appropriate dappSuggestedGasFees',
);
});
it('does not record dappSuggestedGasFees when transaction origin is "metamask"', function () {
const txParams = {
gas: GAS_LIMITS.SIMPLE,
from: '0x0000',
to: '0x000',
value: '0x0',
maxFeePerGas: '0x0',
maxPriorityFeePerGas: '0x0',
};
const generatedTransaction = txStateManager.generateTxMeta({
txParams,
origin: ORIGIN_METAMASK,
2021-06-29 22:08:16 +02:00
});
assert.ok(generatedTransaction);
assert.strictEqual(generatedTransaction.dappSuggestedGasFees, null);
});
it('does not record dappSuggestedGasFees when transaction origin is not provided', function () {
const txParams = {
gas: GAS_LIMITS.SIMPLE,
from: '0x0000',
to: '0x000',
value: '0x0',
maxFeePerGas: '0x0',
maxPriorityFeePerGas: '0x0',
};
const generatedTransaction = txStateManager.generateTxMeta({
txParams,
});
assert.ok(generatedTransaction);
assert.strictEqual(generatedTransaction.dappSuggestedGasFees, null);
});
});
describe('#clearUnapprovedTxs', function () {
it('removes unapproved transactions', function () {
const txMetas = [
2020-11-03 00:41:28 +01:00
{
id: 0,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
},
{
id: 1,
status: TransactionStatus.unapproved,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
2020-11-03 00:41:28 +01:00
metamaskNetworkId: currentNetworkId,
},
{
id: 2,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
2020-11-03 00:41:28 +01:00
metamaskNetworkId: otherNetworkId,
},
{
id: 3,
status: TransactionStatus.confirmed,
txParams: { from: VALID_ADDRESS, to: VALID_ADDRESS_TWO },
2020-11-03 00:41:28 +01:00
metamaskNetworkId: otherNetworkId,
},
];
txMetas.forEach((txMeta) => txStateManager.addTransaction(txMeta));
txStateManager.clearUnapprovedTxs();
2020-11-03 00:41:28 +01:00
const unapprovedTxList = txStateManager
.getTransactions({ filterToCurrentNetwork: false })
.filter((tx) => tx.status === TransactionStatus.unapproved);
assert.equal(unapprovedTxList.length, 0);
});
});
});