-
Notifications
You must be signed in to change notification settings - Fork 29
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
chore: rate limit modal and auto login #22
Conversation
You just need to refresh ~80 times within an hour assuming 30 tasks. I was able to hit these limits while developing the UI. Each "task" that is loaded invokes three requests: 1. the preview 2. the full details 3. sometimes, the image (although i have caching for this) |
Me trying to get rate limited spamming refresh and calling I'm seeing no success so I check my rate limit remaining in a separate script, still 5K. Running it down for QA sake but I'm amazed you were able to hit that locally, I had cache logic disabled and was clearing browser cache every run or two |
It must have been from before I implemented cache then. If it's really not going down due to cache then I'd say don't worry about it anymore. |
Found two scenarios
Got the first one maxing it the first time, then number two the second time. I'd say it's very unlikely to happen but I've added a notice for them anyway. The |
The rate limited cases can be very easily simulated within Cypress by intercepting routes and sending back the appropriate response. It should help you develop and test these cases without having to really spam the endpoint. Also, would be nice to see these testing cases implemented. |
Makes sense. I'm not as exp with testing as you seem to be and my default is usually: mocking requires pre-knowledge of what's going to happen for a fact, as opposed to simulating a response I never knew existed and even if I do know it exists, mocking it sort of defeats the purpose lmao probs a naïve outlook and why I'm not so great with writing them. Always happy to learn and improve but so As part of this PR would you like me to add in test cases to cover what I've done here? @FernandVEYRIER |
There are JSON example responses in the docs, they don't include failed cases but for each route you have the return codes, which I believe should suffice. That would be really great to have some test for sure! |
Not a problem, will get on this today |
Co-authored-by: Mentlegen <9807008+gentlementlegen@users.noreply.github.com>
const resetParsed = rate.reset && new Date(rate.reset * 1000).toLocaleTimeString(); | ||
|
||
if (!rate.user) { | ||
rateLimitModal(`You have been rate limited. Please log in to GitHub to increase your GitHub API limits, otherwise you can try again at ${resetParsed}.`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this take the UTC into account when displayed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.toLocaleTimeString();
It uses local time. This is relevant for the user, and in my testing, it is accurate.
Just realized, this pull needs to be rebased/reopened. Pretty sure this is my code from a long time ago that's already in production.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code is similar I guess but this pr is up to date with development if that's where prod is running from
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good to go when @pavlovcik is
return response.data; | ||
} catch (error) { | ||
if (error instanceof RequestError && error.status === 403) { | ||
await handleRateLimit(providerToken ? octokit : undefined, error); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
await handleRateLimit(providerToken ? octokit : undefined, error); | |
await handleRateLimit(providerToken ?? octokit, error); |
Is this more concise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although if there is a providerToken
and we get an error it'll pass providerToken
as an arg instead of octokit
which would mean rebuilding octokit
within handleRateLimit()
while both invocations of handleRateLimit()
already have octokit
built, one is guaranteed to have a provider token and this one in question is not.
If we make this more concise we litter the rate limit function
I guess if(typeof octokit == "string")
would work instead of if(octokit){}else{}
but typing octokit as string seemed daft when it first popped into my head 😂
Can this be merged? @0x4007 @gentlementlegen |
…lt-conf feat: cypress default configuration
Resolves #20
SUPABASE_REF
and a little helper so it's easier for the likes of myselfI tried to debug why the issues wouldn't load first attempt after logging in following being rate limited but couldn't see why. I presume it's to do with token storage as you clearly see the auth token being handled in the URL.
I couldn't QA for being limited while auth'd for obv reasons but all bases are covered