#sarrielek
rain current
signal vale
Not that I'm aware of. Do you have an example Event ID (evt_abc123) that I can look at to see if anything is forthcoming?
boreal oyster
I have the request Ids at hand if that is ok?
req_sDZLJp8d98dmBb
req_6hs1YGzPoDAqrT
req_xwedhfImlwTmHe
we had 500 errors in 15 days, that's why I wondered
signal vale
Taking a look now
boreal oyster
thanks so much
signal vale
It's possible that you're hitting rate limits: https://stripe.com/docs/rate-limits#object-lock-timeouts
What's the use-case for concurrent API Retrieve requests to the same object?
boreal oyster
those are mainly handling webhook events
signal vale
Do you know why multiple retrievals would be getting sent for the same object though? Like, if your webhook endpoint is configured to receive an invoice.paid event and retrieve the Invoice, why would it do that multiple times?
boreal oyster
There's only one retrieve call
signal vale
Hmmm... let me dig a bit more on this and get back to you
boreal oyster
sure, thanks
signal vale
When you make a POST request to our API, we put a lock on the object that you are trying to modify. We might also put a lock on other resources that are related to your update. The idea is to ensure that no one can attempt to access or modify the same object in parallel while you’re trying to change its value.
While the request runs and makes the modifications, the lock is held. If any other request is done at the same time, it would be blocked from returning until the previous request was done. If that request ends quickly then there’s no issue, the second one takes the lock and makes its own update too even though it was delayed by a few milliseconds (or a few seconds!).
The idea is that this is still usually an integration issue where one part of their code modifies a resource while another one tries to fetch it. You would need to inspect your code to see why this is happening, and (if it cannot be solved through optimizing the code) you can build in a retry systems for failed requests: https://stripe.com/docs/rate-limits#handling-limiting-gracefully
boreal oyster
so the problem is timing in this case, right?
signal vale
Yes, correct
boreal oyster
I'll take another look, thanks!