[Bug]: Sentry sourcemaps misconfigured for Firefox #26466
Assignees
Labels
release-12.4.0
Issue or pull request that will be included in release 12.4.0
Sev2-normal
Normal severity; minor loss of service or inconvenience.
team-extension-platform
type-bug
Comments
Gudahtt
added
Sev2-normal
Gudahtt
added a commit
that referenced
this issue
Aug 16, 2024
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). Fixes #26466
Gudahtt
added a commit
that referenced
this issue
Aug 16, 2024
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). Fixes #26466
Gudahtt
added a commit
that referenced
this issue
Aug 16, 2024
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). Fixes #26466
Gudahtt
added a commit
that referenced
this issue
Aug 16, 2024
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). Fixes #26466
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
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). Fixes #26466
metamaskbot
added
the
release-12.5.0
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
**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). [](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>   </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.
](https://codespaces.new/MetaMask/metamask-extension/pull/26467?quickstart=1){kind=link}
7 tasks
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
**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). [](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>   </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.
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
**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). [](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>   </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.
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
**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). [](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>   </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.
Gudahtt
added a commit
that referenced
this issue
Aug 21, 2024
This is a cherry-pick of #26467 for v12.0.6. Original description: ## **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). [](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>   </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.
gauthierpetetin
added
release-12.4.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Sentry is showing invalid stack traces for Firefox errors, presumably because the sourcemaps we upload are incorrect. We are just uploading the bundles and sourcemaps for MV3 builds, not MV2 (which Firefox still uses).
Expected behavior
Stack traces should work correctly on all Sentry error reports. We should upload all bundles+sourcemaps that are being used in production.
Screenshots/Recordings
No response
Steps to reproduce
These two reports are for the same problem:
The problem is on this line:
metamask-extension/app/scripts/lib/WeakRefObjectMap.ts
Line 44 in 0f11247
See that the stack trace is correct for Chrome, but completely inaccurate for Firefox. I was able to confirm this by analyzing the raw stack trace with the published Firefox build as well.
Error messages or log output
No response
Detection stage
In production (default)
Version
v11.16.6
Build type
None
Browser
Other (please elaborate in the "Additional Context" section)
Operating system
Other (please elaborate in the "Additional Context" section)
Hardware wallet
No response
Additional context
No response
Severity
No response
The text was updated successfully, but these errors were encountered: