#higherhomotopy_api
sudden atlasBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
đ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1352349319583367302
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
strong condor
example of a failed request during that time window: https://dashboard.stripe.com/workbench/logs/req_ugx2ZmuLkYF6Sr
gritty sorrel
Hi there!
Looking
So this isn't a rate limit error - it is a 429 but the error code is lock_timeout rather than rate_limit
It means your request is trying to access an API resource that is currently being acted on by another request, so we return a 429 because the object you're trying to access may have changed between the time you create the request and the time you receive the response
the error message points you at the docs page that you should read here: https://stripe.com/docs/error-codes/lock-timeout
strong condor
I might be looking at the wrong filter in stripe dashboard for those but from our logs we did see this message: Request rate limit exceeded. You can learn more about rate limits here https://stripe.com/docs/rate-limits
gritty sorrel
let me have a look
sudden atlasBOT
cursive heron
Yep should just be rate_limit in the error code field
strong condor
okay that's even more confusing because now I see no events for that time period
but in our internal logs where we're just piping out the response from stripe there's clearly messages that say stripe.error.RateLimitError: Request rate limit exceeded. You can learn more about rate limits here https://stripe.com/docs/rate-limits.
cursive heron
Agreed, not sure why that would be. What was the time period where your system logged that error?
I can try to look on our side
strong condor
12:01 PM EST is the time we have
cursive heron
Gotcha, and today it sounds like?
strong condor
Yes, sorry forgot to include the date
This is a stupid question but rate limit is simply all requests during a time period right? It wouldn't be because it had too many requests from a single cluster? ie:
if we have a rate limit of 2000/min it only triggers if all the requests total from our key exceed 2000/min. It would not be rate limited if we had one of our clusters exceeded 1500/min but our total was still below 2000/min
cursive heron
Correct, the limit is across your account. We add up the calls per second across the different clients that are using your key
And my apologies I am still having trouble finding when your account would have logged this error today. Do you have any Stripe accounts other than the one that that customer object that you provided lives on?
strong condor
where in the dashboard could I find the definite account information?
would it be the id here
verifying before sharing in case it's sensitive info
cursive heron
The bottom of this page will give you the account IDs of all of the accounts that you have dashboard access to.
https://dashboard.stripe.com/settings/user
strong condor
gotcha. yeah it's only
3MFIk84T3nM5kqK4lLcMyGAaeEpvHmCm from waht I can see
cursive heron
Yep, and sending the account IDs here is considered safe because someone would need to log in as you or get your secret key to do anything with them.
strong condor
it's only 3MFIk84T3nM5kqK4lLcMyGAaeEpvHmCm from what I can see
okay discord was lagging out apologies for the duplicate post
cursive heron
Gotcha, I am still struggling to find anything. I will consult my colleagues. And would those logs include errors on the frontend? I don't know if we surface this error like that for Stripe.js, mostly trying to think of things I may not have looked for yet
strong condor
these are backend errors, we are using the python stripe library
cursive heron
Gotcha, thank you. Bringing this to my colleagues
strong condor
and to verify what is our actual rate limit on our account?
cursive heron
By default 100 requests per second
Ah, and it looks like we recently made a change to that rate limiter and a side effect of the change is the errors not showing up in your dashboard request logs.
Taking a step back, were you looking to use that to see what API calls your account was making when this limit was reached?
And/or how to optimize to stay below the limits?
strong condor
they are a variety of requests. I've identified some cron jobs that we can offset to reduce the load a bit. Are there any optimization strategies you would recommend?
I see get payment method details, will update the list as I identify more
cursive heron
Typically for reducing GET requests, our suggestion is to cache the relevant object data if possible in your own DB. Typically the idea is to listen to the webhook events and then store the relevant details for those objects as they come in.
I can also take a look in a sec to see what the most common calls are to see where it would make the most sense to try to reduce calls.
strong condor
yeah I see payment method details, getting customer info, getting subscription info and getting discount info
strong condor
Ah, and it looks like we recently made a change to that rate limiter and a side ...
Is this a bug that will be fixed in the future or intentional?
cursive heron
Gotcha, and you said this is largely for cron jobs where you analyze this data in some way?
strong condor
no the cronjobs are specifically retrieving the customer
the other calls are all routine things that our applications are doing to display information to customers
cursive heron
Gotcha, apologies was bouncing around in other threads. Can you tell me more about when/why the payment method retrieve happens in your flow?
strong condor
It's to display their card information for the customer to see
cursive heron
Ah gotcha, and this is saved card info? It is starting to sound like caching data in general may be the main suggestion. Sometimes I've run into flows where other API calls were being made and there was an opportunity to get the data from one call in another, so there is room for reducing requests there, but that is sounding like it may not be the case here.
strong condor
Diving into the saved card info call right now
it does look like we fetch the customer first and then get it from the default_payment_method field within the response
I assume that's only one request being made there?
would staggering stripe calls within a process also help with the rate limits here
strong condor
Is this a bug that will be fixed in the future or intentional?
also would appreciate a response to this question
cursive heron
My apologies, for dropping that question. As best as I can tell that is intentional, I will definitely file feedback for this though as it is definitely helpful for you to be able to see these errors and when they happened.
And ah in that case you can actually combine those two calls by using expansion. If you pass expand=['invoice_settings.default_payment_method'] you can get the PM details in the API response for the customer
https://docs.stripe.com/expand#includable-properties
strong condor
expand=["subscriptions", "tax_ids", "subscriptions.data.discounts"], are the ones we havecurrently
interesting, are there any limits to the expand keyword?
cursive heron
You can only expand four levels deep, I am not seeing a specific limit on the number of fields that you can expand on each object.
https://docs.stripe.com/api/expanding_objects
strong condor
Okay, that definitely gives us some avenues to improve our rate performance here. as a final ask would you be able to provide the list of failed requests due to rate limits here?
could be a csv output of the events so we can take a look at them
cursive heron
I can't do that myself but if you reach out to our support team they may be able to help you here.
strong condor
What sort of information should be included in the request?
cursive heron
I think what you said here. That you are looking for a list of requests on your account that failed due to non-lock_timeout rate limit errors as they don't show up in your dashboard for you. I don't know if there is a process for running this kind of report but they should be able to look into it or forward that ask to a team that knows more