Hi Olivia! I think this is "expected"—we [catch Suggest exceptions and use `CrashReporting:submitCaughtException`](https://github.com/mozilla-mobile/firefox-android/blob/205ece4bf9234d24135ee780f886367d64b11735/android-components/components/feature/fxsuggest/src/main/java/mozilla/components/feature/fxsuggest/FxSuggestStorage.kt#L94-L106) to submit them to Sentry. Can you tell in Sentry if it's a crash, or an explicitly reported exception? At present, Suggest doesn't expose different error types (bug 1875113), so everything—even the "expected" errors, like network flakiness, database corruption, or an operation being interrupted—will be caught by that `catch (e: SuggestApiException)` block. We can tackle that bug next, to reduce the noise in Sentry. How does S3 sound?
Bug 1875010 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hi Olivia! I think this is "expected"—we [catch Suggest exceptions and use `CrashReporting:submitCaughtException`](https://github.com/mozilla-mobile/firefox-android/blob/205ece4bf9234d24135ee780f886367d64b11735/android-components/components/feature/fxsuggest/src/main/java/mozilla/components/feature/fxsuggest/FxSuggestStorage.kt#L94-L106) to submit them to Sentry as of bug 1869225. Before bug 1869225, we'd swallow exceptions from `ingest`, and leave the ones from `query` uncaught 😬 Now, we catch all exceptions from `ingest` and `query`, and report them all to Sentry. Can you tell in Sentry if it's a crash, or an explicitly reported exception? At present, Suggest doesn't expose different error types (bug 1875113), so everything—even the "expected" errors, like network flakiness, database corruption, or an operation being interrupted—will be caught by that `catch (e: SuggestApiException)` block. We can tackle that bug next, to reduce the noise in Sentry. But until we fix bug 1875113, `SuggestApiException` traces might be a little noisy in Sentry. How does S3 sound?
Hi Olivia! I think this is "expected"—we [catch Suggest exceptions and use `CrashReporting:submitCaughtException`](https://github.com/mozilla-mobile/firefox-android/blob/205ece4bf9234d24135ee780f886367d64b11735/android-components/components/feature/fxsuggest/src/main/java/mozilla/components/feature/fxsuggest/FxSuggestStorage.kt#L94-L106) to submit them to Sentry as of bug 1869225. Before bug 1869225, we'd swallow exceptions from `ingest`, and leave the ones from `query` uncaught 😬 Now, we catch all exceptions from `ingest` and `query`, and report them all to Sentry. Can you tell in Sentry if it's a crash, or an explicitly reported exception? At present, Suggest doesn't expose different error types (bug 1875113), so everything—even the "expected" errors, like network flakiness, database corruption, or an operation being interrupted—will be caught by that `catch (e: SuggestApiException)` block. We can tackle that bug next, to reduce the noise in Sentry. But until we fix bug 1875113, `SuggestApiException` traces might be a little noisy in Sentry. It would still be useful to see these errors, though, so I'm not sure that we'd want to remove `submitCaughtException`. How does S3 sound?