if "request get failed with 403" next backoff happens after quite a long time

[24p3453]

hello, sometimes when i launch preloader it may not start from the first time, so the script gives me a backoff, yeah it might be cool but not 3269 seconds (54.48 minutes)

"Request GET /repos/cueki/casual-pre-loader failed with 403: rate limit exceeded
Setting next backoff to 3269.589769s"

reopening preloader doesnt help because backoff is like a timer that runs in the background, all attempts still result in the "rate limit exceeded"

Version 2.2.1 on win32 (portable)
Application files are located in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader
Project files are written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data
Settings files are in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\config
Log is written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data\casual-pre-loader.log
Request GET /repos/cueki/casual-pre-loader failed with 403: rate limit exceeded
Setting next backoff to 2209.350272s
Version 2.2.1 on win32 (portable)
Application files are located in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader
Project files are written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data
Settings files are in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\config
Log is written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data\casual-pre-loader.log
Request GET /repos/cueki/casual-pre-loader failed with 403: rate limit exceeded
Setting next backoff to 2164.371368s
Version 2.2.1 on win32 (portable)
Application files are located in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader
Project files are written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data
Settings files are in C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\config
Log is written to C:\Users\User\Downloads\casual-preloader-v2.2.1\casual-preloader\userdata\data\casual-pre-loader.log
Request GET /repos/cueki/casual-pre-loader failed with 403: rate limit exceeded
Setting next backoff to 2012.270933s

edit: if preloader will be opened in the background and the next backoff happens, app will launch without any issues

any way to stop this / decrease the waiting time?

[djsigmann]

I've known about this for some time now, we use github's API to check for new releases when the program is launched.
We also use the same API to check for new versions of the bundled mods (factory new warpaints, etc.), whenever the user clicks the relevant button on the first-time-setup screen or the settings menu.

Since github's API has a rate limit of 60 requests per hour for unauthenticated requests, opening and closing the program many times in a short period of time can cause the API to send a timeout notice. The library we use for interacting with the github API, PyGithub, blocks when this happens until the rate limit expires.

This is of course, undesired - so what if we can't check for updates? The program should still launch!

There are a couple measures that could address this:

1. Ignoring timeout messages and simply proceeding as if there are no new updates:
   This is a good idea anyway, and there's no reason not to do it. Could be implemented in like five minutes.

2. Allowing users to authenticate with their github accounts:
   This wouldn't hurt, but as of now, the preloader doesn't use the github API for anything else, so there's not really a good reason to do this; not to mention, many users may not have a github account, and most wouldn't want to connect one regardless.

3. Only checking for new releases every so often (e.g. every ten minutes) instead of every time the program is started:
   This also makes sense and has no drawbacks, users could even be allowed to fine tune this with a setting or disable it if they wish.

@cueki If you have anything you wanna add or comment on, please do.

[djsigmann]

After some closer examination, it'd be quite tedious to monkey patch github.GithubRetry.GithubRetry, and there is an open PR regarding adding a way to not block on hitting ratelimits into the lib directly already.