#jacob-Rate limit

1 messages · Page 1 of 1 (latest)

fossil summit
#

Hi there, can you send me the request ID?

lusty mortar
#

Here's an example id: req_5ACo2FcYvXLNJ5

fossil summit
#

This request returns 200, I don't see any error here.

lusty mortar
#

Here's a few more: req_FawNfYEMWkGhQo req_ncrhwkCgAeQUPt

#

We've had about 30+ occurrences of the error today.

fossil summit
#

All of these three return 200 OK. Can you send me a request that returns error?

lusty mortar
#

Maybe I'm giving you the incorrect ID? This is for a webhook request from Stripe to our server, what ID are you asking for?

#

Here's a webhook failure: evt_1Kq9e3KtITKMNopjsHzs4Sko

fossil summit
#

Where did you see the error message?

lusty mortar
#

In sentry - our checkout success endpoint (/api/payments/webhook) makes a subsequent request to the stripe API, and that's when this failure happened presumably

fossil summit
#

and what kind of request does it make?

lusty mortar
#

we make a couple different calls depending on certain conditions:
stripeClient.customers.retrieve(data.object.customer);
stripeClient.paymentIntents.update(data.object.payment_intent...
stripeClient.subscriptions.retrieve(stripeID)

#

it looks like in some cases the webhook failed but then it went through at a later try (not sure why it tried an hour later...)

fossil summit
#

Yup it means that object is already unlocked when the retry happen.

#

Let me take a look at your logs, one sec

#

Hmm, I don't see any 429 errors in your logs

#

Or is it from another Stripe account?

lusty mortar
#

Strange! I'm definitely seeing this in our stack trace. The account ID is acct_1CQ04CKtITKMNopj

fossil summit
#

Did the error happen today or earlier?

#

OK, I found it

lusty mortar
#

ok cool I think I found the logging too. looks like it's happening for customers endpoints and payment_pages

fossil summit
#

There were too many requests to the same object (cus_LXEFwVt20s4PXX), and it can't be accessed because it's locked by previous request

lusty mortar
#

oh interesting. it looks like it's a mix of 400 errors and 429

#

how did you find that list?

fossil summit
lusty mortar
#

Ohhh it looks like it's being requested from multiple different services we're connected to

fossil summit
lusty mortar
#

So it looks like this wasn't really happening until today based on these logs. I'm seeing some 429s for the other services we're integrated with (Drip, Pipe, Chargedesk), but only today did it start happening for our own server. Any idea if something changed on the Stripe side?

fossil summit
#

429 is a common error that occurs when there are too many requests on the same resource around the same time, and there's why Stripe API libraries has the built-in retry mechanism to remedy it.

lusty mortar
#

Would it happen if there are several requests, or only if there is another process modifying the same customer ?

#

I guess we could increase the number of retries

#

I could also detach one of these other services we aren't using

fossil summit
#

I'd suggest to avoid making requests on the same object (in this case the customer) at the same time.

#

From the log I can see these requests are made by difference services.

lusty mortar
#

So here's one weird thing - in the logs, it looks like it started returning 429s before there were any successful 200 requests for the customer - this makes me think it might be throwing the lock_error due to something going on internally in the Stripe checkout process? It doesn't make sense to me that we'd be rate limited on this resource if there are no other requests visible for it.

#

actually the guide you linked describes this too:

It’s also possible to see lock contention caused by a conflict with an internal Stripe background process—this should be rare, but because it’s beyond user control, we recommend that all integrations are able to retry requests.

#

I'd be curious if other customers were seeing this error today - seems like it could be something that changed on Stripe's end? In either case, I think I'll try to increase the max number of retries

fossil summit
#

We need to check if the 200 requests are sent to the same customer or not, can you share with me the request ID?