fix: Fix MV2 build sourcemap upload (#26467)

**Description**

The sourcemaps for MV2 builds (used for Firefox) were not being uploaded
to Sentry at all. This resulted in invalid stack traces for Firefox
error reports.

The Sentry initiatization has been updated to use a `dist` option,
letting us differentiate between different types of build for the same
version. This is now used to signify which builds are mv2 and which are
mv3. Both distributions are uploaded separately as part of the release
process (for Flask and main builds; we don't have MV2 builds for MMI or
beta).

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

**Related issues**

Fixes #26466

**Manual testing steps**

Unfortunately I don't know of an easy way to test the CircleCI changes.
Those will just have to be read carefully.

We can test the application changes and the Sentry script changes
though. The two outcomes we want to test are:
* The source code and sourcemaps are uploaded correctly for both MV2 and
MV3 builds
* Application bundles for MV2 and MV3 builds are reporting errors
properly tagged as being from an MV2 or MV3 build, and are mapped
correctly in Sentry.

Here are the steps I used to test this:
* Setup a personal Sentry account with a `metamask` project
* Create a Custom Integration in Sentry (Settings -> Custom
Integrations)
  * Steps:
* Navigate to "Settings -> Custom Integrations" on the Sentry dashboard
for your personal Sentry account
* Click the purple "Create New Integration" button on the top-right of
the page
    * Select "Internal integration"
    * Provide any name, and grant it "Admin" access to "Releases"
* Alternatively an Auth Token might work as well, but some of the
commands used by our script to check for pre-existing releases seem to
not work with the `org:ci` scope, which is the only scope available for
Sentry auth tokens.
* Checkout this branch
* Bump the patch version in `package.json` (just in case you need to
re-test, this is an easy way to separate old errors/builds from new
ones)
* Before creating builds, make sure that `SENTRY_DSN_DEV` is set to the
DSN of your personal Sentry account's `metamask` project
* Run `yarn dist:mv2` to create an MV2 build
* Move it to the `dist-mv2` directory (`mv dist dist-mv2`)
* Run `yarn dist` to create an MV3 build
* Before uploading sourcemaps, make sure that `SENTRY_AUTH_TOKEN` is set
to the Auth Token generated from the custom integration earlier.
* Run `yarn sentry:publish --org [your organization]` to upload the MV3
build
* Run `yarn sentry:publish --org [your organization] --dist mv2` to
upload the MV2 build

At this point, you should be able to see the releases on the Sentry
dashboard along with the artifacts. Look in "Settings -> Projects ->
Source Maps" for these. They are labeled by release number and dist.

Now, load each build in your browser (one at a time, never both enabled
at once) and follow these steps:
* Proceed through onboarding, opting in to MetaMetrics
* Navigate to the test-dapp and connect to it
* Click the "INVALID TRANSACTION TYPE (NOT SUPPORTED)" button in the
"Malformed Transactions" section of the test dapp, then reject the
confirmation after it shows up. This should trigger an error in Sentry.
* Look for the error in Sentry and ensure that the frame that shows
`transactionController.updateSecurityAlertResponse(` is mapped to source
code correctly (it should resolve to
`app/scripts/lib/ppom/ppom-util.ts`). Also check that the `dist` is
correct in the "Tags" section of the Sentry issue page.

<details>
<summary> Here are screenshots of what that looked like for me:
</summary>

![Screenshot 2024-08-20 at 19 19
15](https://github.com/user-attachments/assets/36ca0422-71f0-456a-8f1f-5ac980aa5fea)

![Screenshot 2024-08-20 at 19 06
08](https://github.com/user-attachments/assets/25fd681f-c933-41d5-be0e-102fd16f54b2)

</details>

**Screenshots/Recordings**

N/A

**Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

**Pre-merge reviewer checklist**

- [ ] I've manually tested the PR (e.g. pull and build branch, run the
app, test code being changed).
- [ ] I confirm that this PR addresses all acceptance criteria described
in the ticket it closes and includes the necessary testing evidence such
as recordings and or screenshots.

.circleci/config.yml

@@ -1657,9 +1657,15 @@ jobs:
       - run:
           name: Publish main release to Sentry
           command: yarn sentry:publish
+      - run:
+          name: Publish main MV2 release to Sentry
+          command: yarn sentry:publish --dist mv2
       - run:
           name: Publish Flask release to Sentry
           command: yarn sentry:publish --build-type flask
+      - run:
+          name: Publish Flask MV2 release to Sentry
+          command: yarn sentry:publish --build-type flask --dist mv2
       - run:
           name: Publish MMI release to Sentry
           command: yarn sentry:publish --build-type mmi

app/scripts/lib/setupSentry.js

@@ -1,6 +1,7 @@
 import * as Sentry from '@sentry/browser';
 import { Dedupe, ExtraErrorData } from '@sentry/integrations';
 import browser from 'webextension-polyfill';
+import { isManifestV3 } from '../../../shared/modules/mv3.utils';
 import { FilterEvents } from './sentry-filter-events';
 import extractEthjsErrorMessage from './extractEthjsErrorMessage';
 
@@ -191,6 +192,7 @@ export default function setupSentry({ release, getState }) {
   Sentry.init({
     dsn: sentryTarget,
     debug: METAMASK_DEBUG,
+    dist: isManifestV3 ? 'mv3' : 'mv2',
     /**
      * autoSessionTracking defaults to true and operates by sending a session
      * packet to sentry. This session packet does not appear to be filtered out

development/sentry-publish.js

@@ -37,10 +37,15 @@ async function start() {
           default: 0,
           description: 'The MetaMask extension build version',
           type: 'number',
+        })
+        .option('dist', {
+          description:
+            'The MetaMask extension build distribution (typically for MV2 builds, omit for MV3)',
+          type: 'string',
         }),
   );
 
-  const { buildType, buildVersion, org, project } = argv;
+  const { buildType, buildVersion, dist, org, project } = argv;
 
   process.env.SENTRY_ORG = org;
   process.env.SENTRY_PROJECT = project;
@@ -75,19 +80,17 @@ async function start() {
     ]);
   }
 
-  // check if version has artifacts or not
-  const versionHasArtifacts =
-    versionAlreadyExists && (await checkIfVersionHasArtifacts(version));
-  if (versionHasArtifacts) {
-    console.log(
-      `Version "${version}" already has artifacts on Sentry, skipping sourcemap upload`,
-    );
-    return;
-  }
-
   const additionalUploadArgs = [];
+  if (dist) {
+    additionalUploadArgs.push('--dist', dist);
+  }
   if (buildType !== loadBuildTypesConfig().default) {
-    additionalUploadArgs.push('--dist-directory', `dist-${buildType}`);
+    additionalUploadArgs.push(
+      '--dist-directory',
+      dist ? `dist-${buildType}-${dist}` : `dist-${buildType}`,
+    );
+  } else if (dist) {
+    additionalUploadArgs.push('--dist-directory', `dist-${dist}`);
   }
   // upload sentry source and sourcemaps
   await runInShell('./development/sentry-upload-artifacts.sh', [
@@ -109,17 +112,6 @@ async function checkIfVersionExists(version) {
   );
 }
 
-async function checkIfVersionHasArtifacts(version) {
-  const [artifact] = await runCommand('sentry-cli', [
-    'releases',
-    'files',
-    version,
-    'list',
-  ]);
-  // When there's no artifacts, we get a response from the shell like this ['', '']
-  return artifact?.length > 0;
-}
-
 async function doesNotFail(asyncFn) {
   try {
     await asyncFn();

development/sentry-upload-artifacts.sh

@@ -23,20 +23,23 @@ Upload JavaScript bundles and sourcemaps to Sentry
 Options:
   -h, --help               Show help text
   -r, --release <release>  Sentry release to upload files to (defaults to 'VERSION' environment variable)
+  -d, --dist <dist>        Sentry distribution (typically used to identify MV2 builds)
   --dist-directory <path>  The 'dist' directory to use. Defaults to 'dist'.
 EOF
 }
 
 function upload_sourcemaps {
   local release="${1}"; shift
   local dist_directory="${1}"; shift
+  local dist="${1}"; shift
 
-  sentry-cli releases files "${release}" upload-sourcemaps "${dist_directory}"/chrome/ "${dist_directory}"/sourcemaps/ --rewrite --url-prefix '/metamask'
+  sentry-cli releases files "${release}" upload-sourcemaps --dist "${dist}" "${dist_directory}"/chrome/ "${dist_directory}"/sourcemaps/ --rewrite --url-prefix '/metamask'
 }
 
 function main {
   local release=VERSION
   local dist_directory='dist'
+  local dist="mv3"
 
   while :; do
     case "${1-default}" in
@@ -54,6 +57,16 @@ function main {
         release="${2}"
         shift
         ;;
+      -d|--dist)
+        if [[ -z $2 ]]
+        then
+          printf "'dist' option requires an argument.\\n" >&2
+          printf '%s\n' "${__SEE_HELP_MESSAGE__}" >&2
+          exit 1
+        fi
+        dist="${2}"
+        shift
+        ;;
       --dist-directory)
         if [[ -z $2 ]]
         then
@@ -83,7 +96,7 @@ function main {
   fi
 
   printf 'uploading source files and sourcemaps for Sentry release "%s"...\n' "${release}"
-  upload_sourcemaps "${release}" "${dist_directory}"
+  upload_sourcemaps "${release}" "${dist_directory}" "${dist}"
   printf 'all done!\n'
 }
 

shared/modules/mv3.utils.js

@@ -1,11 +1,22 @@
 import browser from 'webextension-polyfill';
 
+const runtimeManifest =
+  global.chrome?.runtime.getManifest() || global.browser?.runtime.getManifest();
+
 /**
- * A boolean indicating whether the manifest of the current extension
- * is set to manifest version 3.
+ * A boolean indicating whether the manifest of the current extension is set to manifest version 3.
+ *
+ * We have found that when this is run early in a service worker process, the runtime manifest is
+ * unavailable. That's why we have a fallback using the ENABLE_MV3 constant. The fallback is also
+ * used in unit tests.
  */
-export const isManifestV3 =
-  browser.runtime.getManifest().manifest_version === 3;
+export const isManifestV3 = runtimeManifest
+  ? runtimeManifest.manifest_version === 3
+  : // Our build system sets this as a boolean, but in a Node.js context (e.g. unit tests) it will
+    // always be a string
+    process.env.ENABLE_MV3 === true ||
+    process.env.ENABLE_MV3 === 'true' ||
+    process.env.ENABLE_MV3 === undefined;
 
 /**
  * A boolean indicating whether the browser supports the offscreen document api.