Exception SuggestApiException$Other Network
Categories
(Firefox for Android :: Search, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox121 | --- | unaffected |
| firefox122 | --- | unaffected |
| firefox123 | --- | affected |
People
(Reporter: olivia, Unassigned)
References
Details
Raw stack trace from Sentry:
SuggestApiException$Other
reason=Error from Remote Settings: Error sending request: [no-sentry] Network error: Java error: "fetch error: java.net.SocketTimeoutException"
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in read at line 5
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in read at line 1
mozilla.appservices.suggest.FfiConverter$DefaultImpls in liftFromRustBuffer at line 13
mozilla.appservices.suggest.FfiConverterRustBuffer$DefaultImpls in liftFromRustBuffer at line 6
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in liftFromRustBuffer at line 2
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in liftFromRustBuffer at line 1
mozilla.appservices.suggest.FfiConverterRustBuffer$DefaultImpls in lift at line 7
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in lift at line 3
mozilla.appservices.suggest.FfiConverterTypeSuggestApiError in lift at line 2
mozilla.appservices.suggest.SuggestApiException$ErrorHandler in lift at line 2
mozilla.appservices.suggest.SuggestApiException$ErrorHandler in lift at line 1
mozilla.appservices.suggest.SuggestKt in checkCallStatus at line 75
mozilla.appservices.suggest.SuggestKt in access$checkCallStatus at line 1
mozilla.appservices.suggest.SuggestStore in ingest at line 70
mozilla.components.feature.fxsuggest.FxSuggestStorage$ingest$2 in invokeSuspend at line 18
kotlin.coroutines.jvm.internal.BaseContinuationImpl in resumeWith at line 9
kotlinx.coroutines.DispatchedTask in run at line 112
kotlinx.coroutines.internal.LimitedDispatcher$Worker in run at line 4
kotlinx.coroutines.scheduling.TaskImpl in run at line 3
kotlinx.coroutines.scheduling.CoroutineScheduler$Worker in run at line 96
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Updated•2 years ago
|
| Reporter | ||
Comment 1•2 years ago
•
|
||
S2 based on volume and unknown impact on results.
Currently, ~12k nightly reports per 24 hours.
Only appears to be in 123 based on reports of 100% AC version 123.0a1 and no reports outside of Nightly, so setting 122 and 121 to unaffected based on that.
| Reporter | ||
Comment 2•2 years ago
•
|
||
Hi Lina,
This bug showed up during crash monitoring. We put it as S2 due to unknown impact, when you have some time, could you take a look at it and re-evaluate?
I also read
Firefox Suggest is only enabled by default on Nightly,
in bug 1869225 comment 5, so maybe its severity should be downgraded or have different status tracking flags?
(basing ni? off of bug 1869225)
Thanks!
Comment 3•2 years ago
•
|
||
Hi Olivia! I think this is "expected"—we catch Suggest exceptions and use CrashReporting:submitCaughtException 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?
| Reporter | ||
Comment 4•2 years ago
|
||
Awesome, thank you for taking a look and providing context!
S3 sounds perfect, mostly just filed this bug to check that no impactful unintended behavior was occurring due to the volume.
Can you tell in Sentry if it's a crash, or an explicitly reported exception?
It isn't listed as unhandled, so it seems to be an explicitly reported exception to me.
Description
•