Allow in-progress form upload to be interrupted on cancel#7203
Allow in-progress form upload to be interrupted on cancel#7203grzesiek2010 wants to merge 3 commits into
Conversation
|
|
||
| try { | ||
| val resultMessage = instanceUploader.uploadOneSubmission(projectId, instance, deviceId, overrideURL, referrer) | ||
| val resultMessage = runInterruptible { |
There was a problem hiding this comment.
If the old process allowed thread interruption I'm guessing this will work, but it still scares me a bit. Is there an exception catch that's happening within the upload code that's handling the InterruptedException that should get thrown?
There was a problem hiding this comment.
Yes, it happens in OpenRosaServerInstanceUploader#uploadOneSubmission. It worked in the same way with the old async task.
There was a problem hiding this comment.
I'm guessing you just mean the blanket Exception catches like here? This still feels like a problem as a CancellationException (the exception that runInterruptible uses instead of InterruptedException) can be thrown in any window where the coroutine "blocks". As far as I'm aware this includes any I/O (network, disk etc.), so there are definitely opportunities for interrupts in places we're not handling it like with DB accesses. This was probably also a problem with the old code, but I don't think it's a problem we should port over to this rework.
I'd prefer opting for a more explicit cancellation mechanism like we use in ServerFormUseCases#downloadForms. This lets us reason about exactly where cancellation can occur and ensure we recover from it correctly.
2 participants
Closes #7188
Why is this the best possible solution? Were any other approaches considered?
In #7008 we reworked the process of uploading filled forms manually by replacing the old Android AsyncTask with coroutines. The old approach was checking if the task is active at the beginning of every iteration (for every selected form) and we implemented the same behavior in the coroutine-based approach. However, it turns out that the old AsyncTask, when canceled, was also interrupting the worker thread, which had the effect of canceling a form upload that was already in progress (mid-upload). We missed that in the new approach, and now I have fixed it by using
runInterruptible.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
We need to test the same things as in #7008.
Do we need any specific form for testing your changes? If so, please attach one.
Any form.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
No.
Before submitting this PR, please make sure you have:
./gradlew connectedAndroidTest(or./gradlew testLab) and confirmed all checks still passDateFormatsTest