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

github token pool from community #5

Open
pi0 opened this issue Nov 7, 2022 · 2 comments
Open

github token pool from community #5

pi0 opened this issue Nov 7, 2022 · 2 comments

Comments

@pi0
Copy link
Member

pi0 commented Nov 7, 2022

Currently, deployment uses one personal token of mine. Using a token pool from the community, we shall load balance requests.

Using limited GitHub tokens, they will be only and only possible to be used for public repo queries.

Some concerns:

  • How we can fairly load the balance
  • How to collect and store them (email?)
  • How to validate them regularly for expiration
@pi0 pi0 mentioned this issue Nov 7, 2022
@pi0 pi0 pinned this issue Nov 10, 2022
@SukkaW
Copy link
Contributor

SukkaW commented Sep 1, 2024

Here is some thoughts:

  • We need to implement an in-memory token pool that does load-balance.
    • The pool should record the quota left from the request header
    • We need to use a response middleware for that
    • The response middleware should also read the status code, when 429 is seen, set the token quota to 0

Also, per GitHub's ToS:

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).

I have my personal bot account @SukkaBot and I can share a PAT of that account.

@pi0
Copy link
Member Author

pi0 commented Sep 2, 2024

Thanks for the inputs dear @SukkaW and willing to donate PAT (i think we can use fine-ganed ones nowadays btw).

Running this server for ~2 years now we barely hit the limit of API usage with the current caching strategy so it is not a high priority.

What i like to start btw would be to have a (cached) healthcheck endpoint that tells if the token is currently rate limited or not. We can also potentially write rate limit errors to a new KV namespace so we first gain better insights.

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

No branches or pull requests

2 participants