#mahad852-lock timeout
woeful ocean
👋 happy to help
there's isn't really a way to force lock timeouts
you're best way to overcome lock timeouts is this https://stripe.com/docs/rate-limits#object-lock-timeouts
foggy vector
retries?
but i think stripe does 2 retries by default...if I am not mistaken
if it's still failing, should we just increase the number of retries?
woeful ocean
can you please share the object ids that are causing you this error?
foggy vector
I unfortunately can't give you the specific IDs right now, but the general flow of how this happens is (taking invoice.payment_succeeded as an example here):
- Listen for webhook event, parse and get event data
- Fetch required object(s) from stripe. In this example, say we retrieve the invoice
- Get the lock_timeout error (happens rather rarely, but happens)
We kinda want to see how the maxRetries work, and also check how our custom exception handling code for this on dev environment before pushing it out to live mode...but as you said, we don't have a way to force this
knotty acorn
there's unfortunately no way to test/force it overall. Everything else you say makes sense. Maybe an option would be to mock your code that calls the API with something that explicitly raises an exception just to test your own retry logic.
foggy vector
yeah that's what i originally thought at first too. eh, will see if I can. But, thanks!
Also, is the maxRetries thing that you suggested above ... is it going to retry the specific request that failed? Also, should we make make any other changes (other than our own custom error handling) in our code base to support maxRetries? Would stripe handle these for us?
for example, is this how it would happen:
- webhook received
- fetch invoice -> lock_timeout so stripe tries again -> fetched successfully
- <other processing on our end>
What I mean to say is, stripe's underlying code would itself handle the fetch invoice request's 429 status and we won't need to do anything else? For us, the code that fetches invoice stays the same?
knotty acorn
is it going to retry the specific request that failed?
yes
Also, should we make make any other changes (other than our own custom error handling) in our code base to support maxRetries?
nothing I can think of
knotty acorn
What I mean to say is, stripe's underlying code would itself handle the fetch in...
it's all handled synchronously in the call in the library , like inside the Stripe/Invoice::retrieve call your code might make, we'll do some retries, the function might take longer to return since it's doing that
foggy vector
Oh alright, yeah that's what I thought. Thanks, that helps!
one last thing...any idea how long the retries usually take? can we accurately/approximately predict how long it would take since with webhooks we'll need to reply back to stripe within 20 seconds
knotty acorn
not sure, would depend how many retries you configure. 20 seconds seems like it's more than enough though