-
Notifications
You must be signed in to change notification settings - Fork 630
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 http corrupted download #5275
Conversation
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
✅ Deploy Preview for nextflow-docs-staging ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
Signed-off-by: Paolo Di Tommaso <paolo.ditommaso@gmail.com>
@pditommaso I've also confirmed this branch catches corrupt HTTP downloads as served by the toy example I gave. Testing this is in a real-world situation is tough since it relies on the intermittent failure of the Cloudflare R2 server. I have oncoanalyser running in a loop configured only to stage and decompress the large VIRUSBreakend database with both Nextflow compiled from this branch and the v24.04.4 release. So far I have only captured one instance of such a server failure, which was in a run with this branch. Your changes look to correct the behaviour: oncoanalyser.nextflow_branch.stdstrm.failure_captured.txt. I'll post here to confirm the negative case under the same conditions where I am able observe that as well. |
Excellent! |
After leaving the oncoanalyser loops to run overnight I've now replicated six fatal failures with v24.04.4 and an additional three successfully handled failures using this branch. Thank you for this fix @pditommaso! |
This PR tries to address the issue with corrupted download reported by #5214.
The overall approach consist on using an input stream filter that checks that the number of bytes read matches the expected one.
However, I think this kind of check is already implemented by the http client, and therefore still persists.