Skip to content
This repository has been archived by the owner on Jan 29, 2021. It is now read-only.

Add proper error handling #6

Closed
kytrinyx opened this issue Jun 21, 2016 · 5 comments
Closed

Add proper error handling #6

kytrinyx opened this issue Jun 21, 2016 · 5 comments

Comments

@kytrinyx
Copy link
Member

Last week we started working on moving track icons into each of the track-specific repositories. See exercism/exercism#2925

I submitted an issue to each track using blazon... and it stopped after submitting to the r track. I'm pretty sure that we got rate-limited by GitHub, and that I don't have error handling in the tool to deal with it.

Thanks to @martinsvalin who not only discovered this, but also submitted the issue to each of the remaining tracks! ❤️

@martinsvalin
Copy link

💜 Happy to help.

On https://github.com/exercism/blazon/blob/master/main.go#L146, errors are logged as fatal. Do you see any logged errors around 2016-06-13T14:18:51Z (creation time from the issue on R)? Github's rate limiting should be a 403 Forbidden, according to their docs.

Since rate limiting is per hour, I don't think retries are a good user experience for a cli tool. Maybe the behaviour should just be to clearly report progress and then abort when the script runs into the rate limit, with a message listing what language tracks remain.

Problem then is the retry. Can tracks be supplied as arguments, instead of fetched from x.exercism.io/v3/tracks? In that case, the tool could print the command to run for the retry, when it runs into Github's rate limit. Sort of how rspec prints copy-pastable rspec commands to make it easier to re-run spec failures.

@kytrinyx
Copy link
Member Author

Do you see any logged [...]

I didn't get any errors at all when I ran it.

Since rate limiting is per hour

It seems odd that we would have used up an hours worth of calls in a single run of the script. Maybe it wasn't that.

Can tracks be supplied as arguments [...]?

I think that would be pretty straight-forward to add, actually.

the tool could print the command to run for the retry

Yes, that would be really handy.

@martinsvalin
Copy link

It could very well be the rate limit if the calls are unauthenticated. From https://developer.github.com/v3/#rate-limiting

For requests using Basic Authentication or OAuth, you can make up to 5,000 requests per hour. For unauthenticated requests, the rate limit allows you to make up to 60 requests per hour.

I see an Authorization header, but no authentication. Not sure how I'd add basic auth safely without having the tool ask for username and password every time. But it's something to explore.

@kytrinyx
Copy link
Member Author

I authenticate using an env var (I use the token authentication).

@kytrinyx
Copy link
Member Author

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants