Open JornR94 opened 4 months ago
Thanks for the report @JornR94. As per the linked RxJava documentation the seeming cause here is that a socket exception (which often just means the network dropped) occurred after the emitter for the exception was already disposed.
While it's possible a bug could be fixed here on Amplify's side, this can also be worked around on the application side by ignoring such errors. The RxJava documentation has a good example, the relevant part is the ignoring of SocketException
.
RxJavaPlugins.setErrorHandler(e -> {
if (e instanceof UndeliverableException) {
e = e.getCause();
}
if ((e instanceof IOException) || (e instanceof SocketException)) {
// fine, irrelevant network problem or API that throws on cancellation
return;
}
if (e instanceof InterruptedException) {
// fine, some blocking code was interrupted by a dispose call
return;
}
if ((e instanceof NullPointerException) || (e instanceof IllegalArgumentException)) {
// that's likely a bug in the application
Thread.currentThread().getUncaughtExceptionHandler()
.handleException(Thread.currentThread(), e);
return;
}
if (e instanceof IllegalStateException) {
// that's a bug in RxJava or in a custom operator
Thread.currentThread().getUncaughtExceptionHandler()
.handleException(Thread.currentThread(), e);
return;
}
Log.warning("Undeliverable exception received, not sure what to do", e);
});
Hi @mattcreaser, thanks for the quick reply! That makes a lot of sense, let me implement that myself to prevent this exception from crashing my app then.
As a side note, I did file this other issue that's pretty similar, but it seems like that's throwing off a StreamResetException
which extends IOException
, so that should also be covered by adding this error handler for RxJava 👍
Are there any plans for integrating this into the AWS Amplify SDK? Thanks Matt!
We'll need to do a little more investigation to see if we can catch these errors internally so that they don't propagate out, I took a quick look but it wasn't immediately obvious where to do so.
We won't be adding an RxJavaPlugins.setErrorHandler
however, as that is incorrect if done by a library, it is only appropriate to use for the end application code.
Makes sense! I can't recall 100%, but I don't think I saw this mentioned anywhere in the implementation docs for Amplify on Android--I think this would be very valuable information to add to the GraphQL/DataStore implementation docs, to prevent unexpected crashes like these after adding the Amplify SDK
Before opening, please confirm:
Language and Async Model
Java
Amplify Categories
GraphQL API, DataStore
Gradle script dependencies
Environment information
Please include any relevant guides or documentation you're referencing
No response
Describe the bug
In our production app, I'm seeing a crash happen occasionally with the Amplify AWS SDK for Android. The crash is a Fatal
SocketException
. Full stack trace below:Fatal Exception: ag.g The exception could not be delivered to the consumer because it has already canceled/disposed the flow or the exception has nowhere to go to begin with. Further reading: https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling | DataStoreException{message=Failure performing sync query to AppSync., cause=ApiException{message=Could not retrieve the response body from the returned JSON, cause=java.net.SocketException: Software caused connection abort, recoverySuggestion=Sorry, we don’t have a recovery suggestion for this error.}, recoverySuggestion=Sorry, we don’t have a recovery suggestion for this error.}
Caused by com.amplifyframework.datastore.DataStoreException Failure performing sync query to AppSync.
Caused by com.amplifyframework.api.ApiException Could not retrieve the response body from the returned JSON
Caused by java.net.SocketException Software caused connection abort
It looks to me like there might be a try/catch block missing somewhere in the flow of this error (in the DataStore
com.amplifyframework.datastore
or the GraphQL API incom.amplifyframework.api
). I flagged a similar issue in this issue that seems related just now.This exception occurred for about 2% of users of our app, which is having a significant impact on the crash rate of our app. I would love your help -- please let me know if I can provide further details to help with solving this.
Just like with the other issue: not sure it's helpful but interestingly, 63% of the exceptions happen on Samsung phones, which is far from the distribution of device-type for our userbase. So there seems to be some relation between the crashes occurring more often on Samsung OS (although it does also happen on other not-customized OEMs like Google Pixels, in this case 8% of crashes on Google phones).
Reproduction steps (if applicable)
No response
Code Snippet
Log output
amplifyconfiguration.json
No response
GraphQL Schema
Additional information and screenshots
No response