-
Notifications
You must be signed in to change notification settings - Fork 306
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
Fix sync state exception handling #1669
Conversation
Remove state emission from catch section of try-catch block. This violates flow exception handling. Signed-off-by: Elly Kitoto <junkmailstoelly@gmail.com>
When an exception occurs while attempting to save a resource, the rest of the process should not be affected. Signed-off-by: Elly Kitoto <junkmailstoelly@gmail.com>
Signed-off-by: Elly Kitoto <junkmailstoelly@gmail.com>
Signed-off-by: Elly Kitoto <junkmailstoelly@gmail.com>
@@ -53,7 +53,7 @@ internal class DownloaderImpl( | |||
) | |||
) | |||
} catch (exception: Exception) { | |||
emit(DownloadState.Failure(ResourceSyncException(resourceTypeToDownload, exception))) |
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.
we may not want to remove this line. sync should emit failure when resource syncing fails.
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.
I see. I have reverted this line so this state can be emitted.
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.
But this needs to be handled not only by the implementers but also in FHirEngineImpl
where the download function is called.
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.
emitting events in catch block is however not recommended because of such unexpected behaviors when the exception is not correctly handle where we are collecting the states for the flow.
saveResolvedResourcesToDatabase(resolved) | ||
} | ||
} catch (exception: Exception) { | ||
Timber.e(exception, "Save remote and resolved conflicting resources to database failed") |
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.
we may not want to just catch exception for resources which have failed to save. it should either show this error to user, or it should do something to log error somewhere to resolve the issue with DB. this can lead to suppress app issues with data collection without getting noticed.
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.
I agree we may need to do more with this error log but do we really want to show the user this error? Is there a strategy in SDK for handling/logging errors?
Signed-off-by: Elly Kitoto <junkmailstoelly@gmail.com>
3b345f5
to
0913137
Compare
- With unmerged PR google#1669 branch
- With unmerged PR google#1669 branch
- With unmerged PR #1 - With unmerged PR google#1917 - With unmerged PR google#1978 - With unmerged PR google#1907 - With unmerged PR google#2016 - With unmerged PR google#2032 - With unmerged PR google#1669
- With unmerged PR #1 - With unmerged PR google#1917 - With unmerged PR google#1978 - With unmerged PR google#1907 - With unmerged PR google#2032 - With unmerged PR google#1669 - With unmerged PR google#2047
- With unmerged PR google#2032 - With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2132 - With unmerged PR #9
- With unmerged PR google#2032 - With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2132
- With unmerged PR google#2032 - With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2132 - With unmerged PR #9 - With unmerged PR google#2076 - With unmerged PR #10
- With unmerged PR google#2032 - With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2132 - With unmerged PR #9 - With unmerged PR google#2076 - With unmerged PR #10
- With unmerged PR google#2032 - With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2132 - With unmerged PR #9 - With unmerged PR google#2076 - With unmerged PR #10
- With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR #9 - With unmerged PR google#2076 - With unmerged PR #10
- With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR #9 - With unmerged PR #10
hey @ellykits - sorry for not having closed this earlier. looking at this PR again i'm not confident this is the route we want to take to fix the problem. what is done here is wrapping the problem in a try catch instead of addressing the exception. for example, if it's network issue, we might need to try again, or if this is a failure we can't recover from we need a way for the application to know about that. additionally, @santosh-pingle is working on #2142 which is very relevant to this problem. so i'll close this PR - but we should still keep the issue open to continue exploring the correct solution. |
- With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2178 - With unmerged PR #9 - With unmerged PR #10
- With unmerged PR #1 - With unmerged PR google#1669 - With unmerged PR google#2178 - With unmerged PR #9 - With unmerged PR #10
- With unmerged PR google#1669 - Wup google#2178 - Wup #9 - Wup #10 - Wup google#2076
- With unmerged PR #11 - Wup google#1669 - Wup google#2076 - Wup #9 - Wup google#2178 - Wup #10
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178 - Wup #10 - Wup google#2230 - Wup google#2262
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR #11 - Wup google#1669 - Wup #9 - Wup google#2178
- With unmerged PR google#11 - Wup google#1669 - Wup google#9 - Wup google#2178
- With unmerged PR google#11 - Wup google#1669 - Wup google#9 - Wup google#2178
IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #1654
Description
Surround the call site of
com.google.android.fhir.impl.FhirEngineImpl#saveRemoteResourcesToDatabase
andcom.google.android.fhir.impl.FhirEngineImpl#saveResolvedResourcesToDatabase
intry-catch
block.Alternative(s) considered
The exception we were getting was a
NullPointerException
Solution would be to add the null check before using the property on this line
com/google/android/fhir/index/ResourceIndexer.kt:317
. This will however only address this type of exception and ignore any other exceptions that may happen.Type
Choose one: Bug fix
Checklist
./gradlew spotlessApply
and./gradlew spotlessCheck
to check my code follows the style guide of this project../gradlew check
and./gradlew connectedCheck
to test my changes locally.