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

Make sure GitHub date-request errors are raised #658

Merged
merged 7 commits into from
Aug 29, 2023

Conversation

nmdefries
Copy link
Contributor

Use httr::stop_for_status to error on any non-successful, non-403 (for which we have special handling) status. Remove the tryCatch wrapper so that the errors actually cause the call to exit.

I'm not sure what errors the tryCatch was originally intended to catch, but there are a couple reasons to remove it. First, without valid dates, downstream calls won't get valid forecast data. And fetching forecast dates is relatively fast. It isn't a big problem to rerun. It also tests GitHub API authentication, which is necessary for time-consuming forecast downloads later.

Copy link
Collaborator

@dshemetov dshemetov left a comment

Choose a reason for hiding this comment

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

Same here, let's bump either minor or patch version number, and otherwise lgtm

},
error = function(e) cat(sprintf("%i. %s\n", i, e$message))
)
forecaster_dates[[i]] <- lubridate::as_date(get_covidhub_forecast_dates(forecasters[i]))
Copy link
Collaborator

Choose a reason for hiding this comment

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

mostly out of scope, but if you know off the top of your head, im curious: why are we using lubridate here instead of just as_date?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure. (All the other as_dates should really be loading directly from lubridate since we're not importing the function.)

@dshemetov
Copy link
Collaborator

Thoughts on adding a retry to get_forecast_dates in case it fails due to some HTTP hiccup?

@nmdefries
Copy link
Contributor Author

@dshemetov I added a retry step. This should be ready so please re-review/merge when you have a chance.

@dshemetov dshemetov merged commit 1e09e47 into main Aug 29, 2023
4 checks passed
@dshemetov dshemetov deleted the ndefries/forward-gh-request-errors branch August 29, 2023 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants