Closed alsorokin closed 7 years ago
LGTM
oo, nice catch!
However, I fail to see how the test added is exercising the abort()
code path? I'm not actually sure what the test is doing other than ensuring a specific amount of data was loaded in. Can you elaborate on what the test is doing, @alsorokin ?
Hey @filmaj, nice to see you 😄
Nevermind this test, it was meant to ensure that my changes does not break downloading two files successively.
The bad news are that the fix is still not working: http://cordova-ci.cloudapp.net:8080/job/cordova-periodic-build-TEST/58/PLATFORM=android-4.4,PLUGIN=cordova-plugin-file-transfer/testReport/junit/cordova-plugin-file-transfer-tests.tests%20__.FileTransfer.methods/download/filetransfer_spec_9_should_not_leave_partial_file_due_to_abort/
After some investigation, I think that calling win
callback after abort()
is kind of expected behavior, at least if we've not calledfail
callback yet and at the moment of abortion the file is ready or is being saved to disk or anything else.
Going to adapt the spec.9
to expect fail
callback, but if we receive win, we just make sure there were no other fail
callbacks called and get on with it.
Updated the branch. Going to test the new fix during the weekend.
Platforms affected
Android
What does this PR do?
Fixes a rare condition on Android when win callback is called even after the
abort()
. Added a test to make sure theaborted
flag is reset correctly at the next download attempt.What testing has been done on this change?
~10 test runs on CI
Checklist