-
Notifications
You must be signed in to change notification settings - Fork 8
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: fix deno download retry logic #104
Conversation
return binaryPath | ||
} finally { | ||
// Try closing and deleting the zip file in an case, error or not | ||
await promisify(file.close.bind(file))() |
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.
Is there a chance that this not fire and we'll await indefinitely?
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.
Well I hope not. And that would be very unexpected behavior. If an error happens, then the callback(err)
would be called -> reject.
* fix: fix deno download retry logic * chore: try different windows deno binary * fix: cleanup on error, should also fix windows tests maybe * chore: deduplicate code * chore: close file * chore: fix rm * chore: fix node 12 * chore: fix review * Update test/downloader.ts
This fixes the retry logic that was introduced in #100.
The old logic would only retry if the fetch throws or the body would be empty, but not if the stream of the request body emits an error, which I think might be happening.
This PR now does two things:
Make the retry enclose the whole download method including fs-operations like unzipping, etc. This ensures now that if the stream emits an error we also retry in this case. If you think we should not add all fs-operations in the retry logic, then we can do that, but the diff gets bigger as I have to split up a bunch of methods.
If the fetch request does not return a 200 status-code we instantly error. Right now we do read the body and try to create the zip which fails, because the body most likely is not a valid zip.
I also added tests, which took the longest here :)
Not sure if the tests work on windows, but please start reviewing, even if windows is failing.