1
0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-26 12:29:06 +01:00
metamask-extension/development/lib/retry.js

43 lines
1.3 KiB
JavaScript
Raw Normal View History

/**
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
* Re-runs the given function until it returns a resolved promise or the number
* of retries is exceeded, whichever comes first (with an optional delay in
* between retries).
*
Version v10.18.4 RC (#15643) * Version v10.18.4 * Fix default currency symbol for `wallet_addEthereumChain` + improve warnings for data that doesn't match our validation expectations (#15201) * set more appropriate default for ticker symbol when wallet_addEthereumChain is called * throw error to dapp when site suggests network with same chainId but different ticker symbol from already added network, instead of showing error and disabled notification to user * Fix Provider Tracking Metrics (#15082) * fix filetype audit (#15334) * Remove decentralized 4byte function signature registry since it contains incorrect signatures and we can't algorithmically check for best option when 4byte.directory is down (#15300) * remove decentralized 4byte function signature registry since it is griefed and we can't algorithmically check for best option when 4byte is down * add migration * remove nock of on chain registry call in getMethodDataAsync test * remove audit exclusion (#15346) * Updates `eth-lattice-keyring` to v0.10.0 (#15261) This is mainly associated with an update in GridPlus SDK and enables better strategies for fetching calldata decoder data. `eth-lattice-keyring` changes: GridPlus/eth-lattice-keyring@v0.7.3...v0.10.0 `gridplus-sdk` changes (which includes a codebase rewrite): GridPlus/gridplus-sdk@v1.2.3...v2.2.2 * Fix 'block link explorer on custom networks' (#13870) * Created a logic for the 'Add a block explorer URL' Removed unused message Message logic rollback Modified history push operation WIP: Pushing before rebasing Applied requested changes Removed unintenionally added code * Lint fix * Metrics fixed * Stop injecting provider on docs.google.com (#15459) * Fix setting of gasPrice when on non-eip 1559 networks (#15628) * Fix setting of gasPrice when on non-eip 1559 networks * Fix unit tests * Fix logic * Update ui/ducks/send/send.test.js Co-authored-by: Mark Stacey <markjstacey@gmail.com> Co-authored-by: Mark Stacey <markjstacey@gmail.com> * [GridPlus] Bumps `eth-lattice-keyring` to v0.11.0 (#15490) * [GridPlus] Bumps `gridplus-sdk` to v2.2.4 (#15561) * remove exclusions for mismatched object jsdoc type casing (#15351) * Improve `tokenId` parsing and clean up `useAssetDetails` hook (#15304) * Fix state creation in setupSentryGetStateGlobal (#15635) * filter breadcrumbs for improved clarity while debugging sentry errors (#15639) * Update v10.18.4 changelog (#15645) * Auto generated changelog * Update 10.18.4 changelog * Run lavamoat:auto * Call metrics event for wallet type selection at the right time (#15591) * Fix Sentry in LavaMoat contexts (#15672) Our Sentry setup relies upon application state, but it wasn't able to access it in LavaMoat builds because it's running in a separate Compartment. A patch has been introduced to the LavaMoat runtime to allow the root Compartment to mutate the `rootGlobals` object, which is accessible from outside the compartment as well. This lets us expose application state to our Sentry integration. * Fix Sentry deduplication of events that were never sent (#15677) The Sentry `Dedupe` integration has been filtering out our events, even when they were never sent due to our `beforeSend` handler. It was wrongly identifying them as duplicates because it has no knowledge of `beforeSend` or whether they were actually sent or not. To resolve this, the filtering we were doing in `beforeSend` has been moved to a Sentry integration. This integration is installed ahead of the `Dedupe` integration, so `Dedupe` should never find out about any events that we filter out, and thus will never consider them as sent when they were not. * Replace `lavamoat-runtime.js` patch (#15682) A patch made in #15672 was found to be unnecessary. Instead of setting a `rootGlobals` object upon construction of the root compartment, we are now creating a `sentryHooks` object in the initial top-level compartment. I hadn't realized at the time that the root compartment would inherit all properties of the initial compartment `globalThis`. This accomplishes the same goals as #15672 except without needing a patch. * Update v10.18.4 changelog * Fix lint issues * Update yarn.lock * Update `depcheck` to latest version (#15690) `depcheck` has been updated to the latest version. This version pins `@babel/parser` to v7.16.4 because of unresolved bugs in v7.16.5 that result in `depcheck` failing to parse TypeScript files correctly. We had a Yarn resolution in place to ensure `@babel/parser@7.16.4` was being used already. That resolution is no longer needed so it has been removed. This should resove the issue the dev team has been seeing lately where `yarn` and `yarn-deduplicate` disagree about the state the lockfile should be in. * Update yarn.lock * Update LavaMoat policy * deduplicate * Update LavaMoat build policy Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com> Co-authored-by: Alex Donesky <adonesky@gmail.com> Co-authored-by: Brad Decker <bhdecker84@gmail.com> Co-authored-by: Alex Miller <asmiller1989@gmail.com> Co-authored-by: Filip Sekulic <filip.sekulic@consensys.net> Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com> Co-authored-by: Dan J Miller <danjm.com@gmail.com> Co-authored-by: Mark Stacey <markjstacey@gmail.com> Co-authored-by: seaona <54408225+seaona@users.noreply.github.com> Co-authored-by: seaona <mariona@gmx.es> Co-authored-by: PeterYinusa <peter.yinusa@consensys.net>
2022-08-24 20:57:47 +02:00
* @param {object} args - A set of arguments and options.
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
* @param {number} args.retries - The maximum number of times to re-run the
* function on failure.
* @param {number} args.delay - The amount of time (in milliseconds) to wait in
* between retries. (Default: 0)
* @param {string} args.rejectionMessage - The message for the rejected promise
* this function will return in the event of failure. (Default: "Retry limit
* reached")
* @param {Function} functionToRetry - The function that is run and tested for
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
* failure.
* @returns {Promise<null | Error>} a promise that either resolves to null if
* the function is successful or is rejected with rejectionMessage otherwise.
*/
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
async function retry(
{ retries, delay = 0, rejectionMessage = 'Retry limit reached' },
functionToRetry,
) {
let attempts = 0;
while (attempts <= retries) {
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
if (attempts > 0 && delay > 0) {
await new Promise((resolve) => setTimeout(resolve, delay));
}
try {
await functionToRetry();
return;
} catch (error) {
console.error(error);
} finally {
attempts += 1;
}
}
Fix 'yarn setup' on M1 Macs (#11887) There are a few issues encountered when running `yarn setup` on new Apple Silicon (aka M1, aka arm64) Macs: * The script halts when attempting to run the install step for the `chromedriver` package with the message "Only Mac 64 bits supported". This is somewhat misleading as it seems to indicate that chromedriver can only be installed on a 64-bit Mac. However, what I think is happening is that the installation script for `chromedriver` is not able to detect that an arm64 CPU *is* a 64-bit CPU. After looking through the `chromedriver` repo, it appears that 87.0.1 is the first version that adds a proper check ([1]). Note that upgrading chromedriver caused the Chrome-specific tests to fail intermittently on CI. I was not able to 100% work out the reason for this, but ensuring that X (which provides a way for Chrome to run in a GUI setting from the command line) is available seems to fix these issues. * The script also halts when attempting to run the install step for the `electron` package. This happens because for the version of `electron` we are using (9.4.2), there is no available binary for arm64. It appears that Electron 11.x was the first version to support arm64 Macs ([2]). This is a bit trickier to resolve because we don't explicitly rely on `electron` — that's brought in by `react-devtools`. The first version of `react-devtools` that relies on `electron` 11.x is 4.11.0 ([3]). [1]: https://github.com/giggio/node-chromedriver/commit/469dd0a6ee23540bfa832b5f09b4cbde3e152010 [2]: https://www.electronjs.org/blog/apple-silicon [3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
2021-09-01 18:40:40 +02:00
throw new Error(rejectionMessage);
}
module.exports = { retry };