-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace Fabric Crashlytics with Sentry #1376
Conversation
3022bcb
to
aa8ee4d
Compare
9e8d773
to
3daeba3
Compare
// Check if user passed accepted opt-in to metrics | ||
const metricsOptIn = await AsyncStorage.getItem('@MetaMask:metricsOptIn'); | ||
if (__DEV__) { | ||
args.unshift('[MetaMask DEBUG]:'); | ||
console.log.apply(null, args); // eslint-disable-line no-console | ||
} else if (metricsOptIn === 'agreed') { | ||
Fabric.Crashlytics.log(JSON.stringify(args)); | ||
addBreadcrumb({ | ||
message: JSON.stringify(args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a lot more useful info we could add here to the breadcrumb, but this is a good start at least. I might improve this later by changing the arguments to allow logging structured data, rather than an arbitrary array
To test this locally, I added the line You can test the breadcrumbs by adding a I wasn't sure how to replicate a native crash offhand - that's something we should test as well. |
defaults.url=https://sentry.io/ | ||
defaults.org=metamask | ||
defaults.project=test-metamask-mobile | ||
auth.token= |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does the auth token work? When is it needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is used to publish sourcemaps, which happens as part of the release build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A similar command is in place for the extension (sentry:publish
) which also needs a token; any submission of release artifacts requires this token.
Unfortunately with React Native, this command is integrated with the normal build process; I'm not sure how to pull it into a separate step. The modifications to the build process were done automatically when linking @sentry/react-native
, and I wasn't eager to customize them. At least it's automatically skipped in dev mode though, so it shouldn't affect dev environments
@@ -18,14 +17,15 @@ export default class Logger { | |||
* @returns - void | |||
*/ | |||
static async log(...args) { | |||
// TODO use crashlytics opt-in | |||
// Check if user passed accepted opt-in to metrics | |||
const metricsOptIn = await AsyncStorage.getItem('@MetaMask:metricsOptIn'); | |||
if (__DEV__) { | |||
args.unshift('[MetaMask DEBUG]:'); | |||
console.log.apply(null, args); // eslint-disable-line no-console | |||
} else if (metricsOptIn === 'agreed') { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does mobile metrics opt-in include a note about error reporting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure. I was curious about this as well; on the extension we don't ask for permission to collect error information at all.
I've completed code review.
|
4a3f7e3
to
8c4334e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
working on IOS! 🥇
24475fa
to
656e725
Compare
The Logger now logs to `console.log` exclusively.
Errors are reported using `captureException`, and non-errors are added as breadcrumbs. This means the non-error events won't be directly sent to Sentry, but they will be included as context for any errors that do occur. The sentry configuration is mainly in the `sentry.debug.properties` file. The only config outside of that file is the DSN used for reporting errors, which is hard-coded in the `setupSentry.js` module. There are three separate sets of config: default, debug, and release. The default config is missing the auth token, so it can't be used to publish source maps. However, builds that use the default config will still correctly report errors to the `test-metamask-mobile` Sentry project. The debug config is identical to the default config except that it includes the auth token. The debug config is for publishing any non-production builds (e.g. testing, pre-releases). The release configuration is to be used for production builds only. This is the only config that sends errors to the `metemask-mobile` Sentry project. The debug and release config files have not been added to the repo. They are automatically instantiated from the example files if the `MM_SENTRY_AUTH_TOKEN` environment variable is set. Setting this environment variable in CI should allow publishing from CI. Closes #1321
The SENTRY_PROPERTIES environment variable is used at different directory levels in the Android and iOS builds respectively; it's used one level down with iOS, but two levels down for Android. This means the properties path used is incorrect on iOS at the moment. Instead an absolute path is now used, to prevent any such errors in the future. The error message for the missing auth token has been improved as well.
The properties file is now checked to ensure the auth token is present, so the build can fail early rather than partway through. The logic for handling the auth token has been moved to a separate function as well, so it can be shared between the release and prerelease builds.
The Sentry environment is set to `local` by default (e.g. for dev builds), but the build script now requires it to be explicitly set for release builds. This is to ensure it isn't missed in the production builds, which are done manually.
Whenever using the `throw` keyword or calling `reject` in a Promise, the value passed should be an Error. Various tools expect thrown "errors" to be errors; this is the convention. Using Error types is also more useful for debugging, as they have stack traces.
`Logger.error` now expects an actual error object as the first argument. This allows us to submit proper Errors with stack traces to Sentry. The second parameter is an optional set of extra data, which gets attached to the Error and is viewable on Sentry in the "Additional Data" section of the error report. Unfortunately any messages added to contextualize errors had to be submitted as extra data instead of as a wrapper Error. Wrapper error types provide for a richer debugging experience in general, because you get additional context for the error plus an additional stack trace to help trace the flow of the error. Sentry even has an Integration meant to facilitate this pattern, the `LinkedErrors` integration. But unfortunately that integration doesn't seem to work with React Native, so that option was off the table.
The most recent Sentry packages have better support for capturing native crashes on Android. I had held off on this update at first beceause I thought it required React Native >= 0.60, but apparently not. It still works on 0.59, just not as well (no sourcemaps)
It was expecting an alphabetical key instead of an alphanumeric one.
This reverts commit 2375f80.
* Remove Fabric and Crashlytics The Logger now logs to `console.log` exclusively. * Add Sentry reporting Errors are reported using `captureException`, and non-errors are added as breadcrumbs. This means the non-error events won't be directly sent to Sentry, but they will be included as context for any errors that do occur. The sentry configuration is mainly in the `sentry.debug.properties` file. The only config outside of that file is the DSN used for reporting errors, which is hard-coded in the `setupSentry.js` module. There are three separate sets of config: default, debug, and release. The default config is missing the auth token, so it can't be used to publish source maps. However, builds that use the default config will still correctly report errors to the `test-metamask-mobile` Sentry project. The debug config is identical to the default config except that it includes the auth token. The debug config is for publishing any non-production builds (e.g. testing, pre-releases). The release configuration is to be used for production builds only. This is the only config that sends errors to the `metamask-mobile` Sentry project. The debug and release config files have not been added to the repo. They are automatically instantiated from the example files if the `MM_SENTRY_AUTH_TOKEN` environment variable is set. Setting this environment variable in CI should allow publishing from CI. Closes #1321 * Use absolute path for Sentry file The SENTRY_PROPERTIES environment variable is used at different directory levels in the Android and iOS builds respectively; it's used one level down with iOS, but two levels down for Android. This means the properties path used is incorrect on iOS at the moment. Instead an absolute path is now used, to prevent any such errors in the future. The error message for the missing auth token has been improved as well. * Improve handling of missing auth token The properties file is now checked to ensure the auth token is present, so the build can fail early rather than partway through. The logic for handling the auth token has been moved to a separate function as well, so it can be shared between the release and prerelease builds. * Force setting METAMASK_ENVIRONMENT explicitly for release builds The Sentry environment is set to `local` by default (e.g. for dev builds), but the build script now requires it to be explicitly set for release builds. This is to ensure it isn't missed in the production builds, which are done manually. * Ensure only Errors are thrown/rejected Whenever using the `throw` keyword or calling `reject` in a Promise, the value passed should be an Error. Various tools expect thrown "errors" to be errors; this is the convention. Using Error types is also more useful for debugging, as they have stack traces. * Update `Logger.error` function signature `Logger.error` now expects an actual error object as the first argument. This allows us to submit proper Errors with stack traces to Sentry. The second parameter is an optional set of extra data, which gets attached to the Error and is viewable on Sentry in the "Additional Data" section of the error report. Unfortunately any messages added to contextualize errors had to be submitted as extra data instead of as a wrapper Error. Wrapper error types provide for a richer debugging experience in general, because you get additional context for the error plus an additional stack trace to help trace the flow of the error. Sentry even has an Integration meant to facilitate this pattern, the `LinkedErrors` integration. But unfortunately that integration doesn't seem to work with React Native, so that option was off the table. * Update `@sentry` packages to latest The most recent Sentry packages have better support for capturing native crashes on Android. I had held off on this update at first because I thought it required React Native >= 0.60, but apparently not. It still works on 0.59, just not as well (no sourcemaps)
Remove Fabric and Crashlytics
Add Sentry reporting
Errors are reported using
captureException
, and non-errors are added as breadcrumbs. This means the non-error events won't be directly sent to Sentry, but they will be included as context for any errors that do occur.The sentry configuration is mainly in the
sentry.debug.properties
file. The only config outside of that file is the DSN used for reporting errors, which is hard-coded in thesetupSentry.js
module.There are three separate sets of config: default, debug, and release. The default config is missing the auth token, so it can't be used to publish source maps. However, builds that use the default config will still correctly report errors to the
test-metamask-mobile
Sentry project.The debug config is identical to the default config except that it includes the auth token. The debug config is for publishing any non-production builds (e.g. testing, pre-releases).
The release configuration is to be used for production builds only. This is the only config that sends errors to the
metemask-mobile
Sentry project.The debug and release config files have not been added to the repo. They are automatically instantiated from the example files if the
MM_SENTRY_AUTH_TOKEN
environment variable is set. Setting this environment variable in CI should allow publishing from CI.Closes #1321