Skip to content
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

Merged
merged 9 commits into from
Aug 26, 2022
Merged

fix: fix deno download retry logic #104

merged 9 commits into from
Aug 26, 2022

Conversation

danez
Copy link
Contributor

@danez danez commented Aug 24, 2022

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.

@danez danez added the type: bug code to address defects in shipped code label Aug 24, 2022
@danez danez requested review from jackiewmacharia and a team August 24, 2022 16:08
@danez danez self-assigned this Aug 24, 2022
return binaryPath
} finally {
// Try closing and deleting the zip file in an case, error or not
await promisify(file.close.bind(file))()
Copy link
Member

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?

Copy link
Contributor Author

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.

src/downloader.ts Outdated Show resolved Hide resolved
src/downloader.ts Outdated Show resolved Hide resolved
@danez danez requested review from eduardoboucas and a team August 25, 2022 09:56
eduardoboucas
eduardoboucas previously approved these changes Aug 26, 2022
src/downloader.ts Show resolved Hide resolved
test/downloader.ts Outdated Show resolved Hide resolved
@danez danez merged commit 270290c into main Aug 26, 2022
@danez danez deleted the fix-retry-logic branch August 26, 2022 13:39
Skn0tt pushed a commit to netlify/build that referenced this pull request Apr 23, 2024
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug code to address defects in shipped code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants