Multipart Uploads not completing when app is terminated by the system in the background #3173
Comments
|
Hi, @thezonie There is one behavior you described I disagree with:
Correct me if I am wrong. Thanks for reaching out. |
ruiguoamz
added
the
pending-community-response
|
Thanks for the response, @ruiguoamz Since the As per https://developer.apple.com/documentation/foundation/urlsessionconfiguration/1407496-background:
@cbommas references the "retrieving the status of the transfers that were in progress at the time of termination" near the Manually relaunching the app into the foreground after the system has terminated it while the background transfers were still in progress and re-instantiating the When the app is terminated by the system, once all of the 5MB chunks complete, the app is relaunched in the background when the |
|
The issue appears to be related to the recovery process, when the app re-registers the In the aws-sdk-ios/AWSS3/AWSS3TransferUtility.m Line 610 in a08952e |
palpatim
added
follow up
|
@thezonie Thanks very much for the investigation and link. We'll take a look and update this issue when we have more info. |
|
I believe that I am experiencing the same issue here. For my primary use case of uploading large files like videos, this is essentially a blocker for me to ship my app since it may be incredibly common for for my users to have large multipart uploads terminated by later versions of iOS (due to memory pressure, etc.) I have some experience with URLSession and will dig in deeper today to see if I can offer any help. If any of the primary maintainers have a confident prescription for how to fix it or any additional guidance, I will gladly try to provide a patch. I'm also happy to help with testing a patch if anyone is nearly there. Has anything new been learned since the last comment or an ETA for a patch put in place? |
|
I was able to dig into this a big deeper today, and I've written a short novella because it helps me to better understand what's going on (and hopefully helps someone else who's more familiar with this code to guide me in the right direction...)
Here's the end of the logging output for the successful suspend/resume situation: As expected, this was a successful multi-part upload, and I can confirm that the file indeed made it into S3. Here's some relevant logging output from the unsuccessful terminate/restart situation: Here's my interpretation of the logging so far after spending a little bit of time with the XCode debugger [updated]:
After adding some additional logging I discovered that the upload is failing because Here's what I think is happening:
Someone else should take a look as well, but what I've been able to consistently find by tracing the source. I'm currently thinking about the best fix for preventing |
|
Hi @ptwobrussell, thanks for the deep dive into this issue and the detailed write-up on your investigation. This is really helpful in understanding what's going on in the TransferUtility code. It's clear that the @thezonie I tried setting up Charles as the http proxy for my iOS device connected to the macbook and ran into some issues with installing the SSL certificate. I was following this and could not get the device to load the certificate from the safari/chrome broswer, so it may be an issue on my end. Just want get more information on your repro steps
|
|
@lawmicha - awesome! FWIW, I was able to consistently reproduce without using Charles (though I've previously overcome the SSL issues with my XCode setup; it was tricky for me as well) and could use more fine grained logging to confirm what @thezonie reported. My PR did resolve the issue so at the very least I think you will be able to confirm that it empirically fixes the bug and see that the patch makes sense once you read it. There may be better ways of generating unique IDs than what I put forth, though, I feel pretty confident about the core fix |
palpatim
added
work in progress
|
Hi @ptwobrussell, thanks for the investigation and testing out the #3282 we've released it in 2.21.0 I will optimisically close this issue, please let us know if you have any issues. |
Describe the bug
Multipart uploads appear to consist of an InitiateMultipartUpload HTTP POST, followed by a series of 5MB chunk PUT requests, finished off by a CompleteMultipartUpload POST containing the chunk info. Once the CompleteMultipartUpload is successful, the uploaded is complete, and the file appears in the S3 bucket.
If the app is terminated by the system while in the background during an upload, all of the 5MB chunk background transfers complete, but there is no final CompleteMultipartUpload POST to finish the transfer. Additionally, the 5MB chunks are re-uploaded periodically, as the system attempts to finish the upload, but it never sends the final CompleteMultipartUpload.
To Reproduce
Steps to reproduce the behavior:
Observed Behavior
Using Charles Proxy or similar, you can see the 5MB chunk uploads complete, but no final CompleteMultipartUpload. The uploaded file does not appear in the S3 bucket.
Expected Behavior
Once all of the 5MB chunk uploads are complete, the final CompleteMultipartUpload request should be made to complete the upload, and the file should appear in the S3 bucket.
If the app is left in the foreground or is sent to the background with an upload running that completes before the system terminates it, the upload completes as expected.
Areas of the SDK you are using (AWSMobileClient, Cognito, Pinpoint, IoT, etc)?
AWSS3TransferUtility
Environment(please complete the following information):
Device Information (please complete the following information):
The text was updated successfully, but these errors were encountered: