You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
giscus authenticates as the app (bot) for the following operations:
Fetching repository information (repositoryId and categoryIds)
Fetching discussions anonymously (not signed in)
Posting new discussions (if no matching discussion exists)
For all other operations (posting comments, reactions, etc.) giscus authenticates as the user, so the 5000 points/hour limit is imposed on the user. In this case, I think the 5000 points/hour limit is generous. Going beyond that limit is highly unlikely, but possible (e.g. if the user also uses GitHub's API by other means).
The bot hitting the 5000 points/hour is more likely, especially if we have a lot of users (or maybe a few but with high traffic). At the very least, I think we should handle this case. A possible solution is to show an error message indicating the rate limit and a hint to sign in. Though at this point I think it wouldn't be much effort to also handle the case where the user already hits the rate limit.
The app's token limit is imposed on its installation, not on the app itself. Because we request the token to be scoped within the specified repository, the 5000 points/hour limit is shared per installation, not to all users.
Following #86.
GitHub's GraphQL API has a limit of 5000 query points/hour.
giscus authenticates as the app (bot) for the following operations:
repositoryId
andcategoryIds
)For all other operations (posting comments, reactions, etc.) giscus authenticates as the user, so the 5000 points/hour limit is imposed on the user. In this case, I think the 5000 points/hour limit is generous. Going beyond that limit is highly unlikely, but possible (e.g. if the user also uses GitHub's API by other means).
The bot hitting the 5000 points/hour is more likely, especially if we have a lot of users (or maybe a few but with high traffic). At the very least, I think we should handle this case. A possible solution is to show an error message indicating the rate limit and a hint to sign in. Though at this point I think it wouldn't be much effort to also handle the case where the user already hits the rate limit.
For reference, utterances only sends a warning to the console when it hits the rate limit. It's also much easier to detect it on the REST API since you can just check the header. With the GraphQL API, you need to explicitly include
rateLimit
in the query.The text was updated successfully, but these errors were encountered: