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

Check that we have downloaded the file successfully #4627

Merged
merged 3 commits into from
Oct 30, 2024

Conversation

lkerford
Copy link
Contributor

When we are downloading files we should check that the http call was successful instead of assuming that because no exception was thrown that the http status was successful. In the case were we get a 408, we don't throw an exception. This results in a InputStream of null to be returned. When reading from a InputStream of null, it infinitely returns a list of null bytes. In our use case we end up writing null to a temporary file until we run out of disk space

We can also make this change in the HttpSender and throw when we get a none successful http code

When we are downloading files we should check that the http call was successful instead of assuming that because no exception was thrown that the http status was successful. In the case were we get a 408, we don't throw an exception. This results in a InputStream of null to be returned. When reading from a InputStream of null, it infinitely returns a list of null bytes. In our use case we end up writing null to a temporary file until we run out of disk space

We can also make this change in the `HttpSender` and throw when we get a none successful http code
Copy link
Member

@sambsnyd sambsnyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Tim's feedback about asserting exceptions but otherwise this looks good

@timtebeek timtebeek added the bug Something isn't working label Oct 29, 2024
@lkerford
Copy link
Contributor Author

I'm also going to update the test to each have their own cache, because at the moment only the 1st test running the expect logic while the others are falling back to the cache and aren't testing the expected logic

@@ -93,7 +93,11 @@ public InputStream getInputStream(ExecutionContext ctx) {
Path localArchive = cache.compute(uri, () -> {
//noinspection resource
HttpSender.Response response = httpSender.send(httpSender.get(uri.toString()).build());
return response.getBody();
if (response.isSuccessful()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question to team:
should we be doing some type of retry here to improve reliability with transient errors like network glitch or delays?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If want to implement retires, I think we might want to move this change to the HttpSender, I suspect other endpoints could benefit from it

@lkerford lkerford merged commit d030c63 into main Oct 30, 2024
2 checks passed
@lkerford lkerford deleted the check-if-http-call-was-a-success branch October 30, 2024 15:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

6 participants