1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-22 18:00:18 +01:00
metamask-extension/ui/helpers/utils/tx-helper.ts

62 lines
1.9 KiB
TypeScript
Raw Normal View History

import log from 'loglevel';
import { transactionMatchesNetwork } from '../../../shared/modules/transaction.utils';
import { valuesFor } from './util';
2020-11-03 00:41:28 +01:00
export default function txHelper(
unapprovedTxs: Record<string, any> | null,
unapprovedMsgs: Record<string, any> | null,
personalMsgs: Record<string, any> | null,
decryptMsgs: Record<string, any> | null,
encryptionPublicKeyMsgs: Record<string, any> | null,
typedMessages: Record<string, any> | null,
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
networkId?: string | null,
chainId?: string,
): Record<string, any> {
log.debug('tx-helper called with params:');
2020-11-03 00:41:28 +01:00
log.debug({
unapprovedTxs,
unapprovedMsgs,
personalMsgs,
decryptMsgs,
encryptionPublicKeyMsgs,
typedMessages,
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
networkId,
chainId,
});
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 txValues = networkId
? valuesFor(unapprovedTxs).filter((txMeta) =>
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
transactionMatchesNetwork(txMeta, chainId, networkId),
2020-11-03 00:41:28 +01:00
)
: valuesFor(unapprovedTxs);
2017-09-29 18:24:08 +02:00
const msgValues = valuesFor(unapprovedMsgs);
const personalValues = valuesFor(personalMsgs);
const decryptValues = valuesFor(decryptMsgs);
const encryptionPublicKeyValues = valuesFor(encryptionPublicKeyMsgs);
const typedValues = valuesFor(typedMessages);
const allValues = txValues
.concat(msgValues)
.concat(personalValues)
.concat(decryptValues)
.concat(encryptionPublicKeyValues)
.concat(typedValues)
.sort((a, b) => {
return a.time - b.time;
});
log.debug(`tx helper found ${txValues.length} unapproved txs`);
log.debug(`tx helper found ${msgValues.length} unsigned messages`);
2020-11-03 00:41:28 +01:00
log.debug(
`tx helper found ${personalValues.length} unsigned personal messages`,
);
log.debug(`tx helper found ${decryptValues.length} decrypt requests`);
2020-11-03 00:41:28 +01:00
log.debug(
`tx helper found ${encryptionPublicKeyValues.length} encryptionPublicKey requests`,
);
log.debug(`tx helper found ${typedValues.length} unsigned typed messages`);
2017-02-23 01:23:13 +01:00
return allValues;
Fix lint warnings Fixed warnings: ```md app/scripts/controllers/computed-balances.js + 35:27 warning Missing space before function parentheses space-before-function-paren + 41:14 warning 'address' is never reassigned. Use 'const' instead prefer-const + 61:9 warning 'updater' is never reassigned. Use 'const' instead prefer-const + 68:11 warning 'newState' is never reassigned. Use 'const' instead prefer-const app/scripts/controllers/network.js + 104:29 warning Missing space before function parentheses space-before-function-paren app/scripts/lib/createLoggerMiddleware.js + 4:32 warning Missing space before function parentheses space-before-function-paren + 15:2 warning Newline required at end of file but not found eol-last app/scripts/lib/createOriginMiddleware.js + 4:32 warning Missing space before function parentheses space-before-function-paren + 9:2 warning Newline required at end of file but not found eol-last app/scripts/lib/createProviderMiddleware.js + 5:34 warning Missing space before function parentheses space-before-function-paren + 13:2 warning Newline required at end of file but not found eol-last app/scripts/lib/events-proxy.js + 1:50 warning Missing space before function parentheses space-before-function-paren + 31:2 warning Newline required at end of file but not found eol-last app/scripts/lib/nodeify.js + 2:22 warning Missing space before function parentheses space-before-function-paren + 2:24 warning Missing space before opening brace space-before-blocks + 5:18 warning Missing space before function parentheses space-before-function-paren + 5:20 warning Missing space before opening brace space-before-blocks app/scripts/lib/pending-balance-calculator.js + 16:19 warning Missing space before function parentheses space-before-function-paren app/scripts/lib/pending-tx-tracker.js + 85:11 warning '||' should be placed at the end of the line operator-linebreak + 87:11 warning '||' should be placed at the end of the line operator-linebreak + 88:11 warning '||' should be placed at the end of the line operator-linebreak + 90:11 warning '||' should be placed at the end of the line operator-linebreak + 91:11 warning '||' should be placed at the end of the line operator-linebreak app/scripts/lib/port-stream.js + 3:22 warning Missing space before function parentheses space-before-function-paren + 3:24 warning Missing space before opening brace space-before-blocks app/scripts/lib/tx-gas-utils.js + 84:2 warning Newline required at end of file but not found eol-last app/scripts/lib/tx-state-history-helper.js + 12:37 warning Missing space before function parentheses space-before-function-paren + 23:30 warning Missing space before function parentheses space-before-function-paren + 30:23 warning Missing space before function parentheses space-before-function-paren + 35:28 warning Missing space before function parentheses space-before-function-paren + 41:2 warning Newline required at end of file but not found eol-last app/scripts/lib/tx-state-manager.js + 94:13 warning 'value' is never reassigned. Use 'const' instead prefer-const ui/app/reducers.js + 45:7 warning 'state' is never reassigned. Use 'const' instead prefer-const + 53:7 warning 'stateString' is never reassigned. Use 'const' instead prefer-const ui/lib/tx-helper.js + 27:2 warning Newline required at end of file but not found eol-last ui/app/components/account-dropdowns.js + 163:1 warning More than 2 blank lines not allowed no-multiple-empty-lines ui/app/components/menu-droppo.js + 22:7 warning 'style' is never reassigned. Use 'const' instead prefer-const ui/app/components/shapeshift-form.js + 135:11 warning '&&' should be placed at the end of the line operator-linebreak ui/app/components/typed-message-renderer.js + 35:25 warning Missing space before function parentheses space-before-function-paren + 42:2 warning Newline required at end of file but not found eol-last mascara/server/index.js + 11:42 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 12:36 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 13:33 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 14:40 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 20:29 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 21:29 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat + 26:40 warning Use path.join() or path.resolve() instead of + to create paths no-path-concat ```
2017-10-21 21:06:39 +02:00
}