#jarcher
small shuttle
This happens when I'm using a test clock to advance subscription renewals. and we're gettin the invoice for charge event on the charge.succeeded webhook
amber rose
Hello, this happens when too many API requests are trying to access the same object at once. https://stripe.com/docs/rate-limits#object-lock-timeouts
Interesting are you not making new API calls other than the advance call?
small shuttle
No, it's the advance call and we're making picking up on the subscription renewal using the charge.succeeded event
there's one call to retrieve the invoice, and it fails
could it be that Stripe is also trying to read/update the invoice at the same time? cuz there are lots of webhooks that all fire within the same 2-3 seconds of each other
amber rose
Interesting, so one call to advance the clock. While it is advancing you get an invoice related event and try to retrieve it, then we send back the lock error?
small shuttle
that's what I'm seeing, yes
amber rose
That does seem like a solid possibility especially if the invoice was going to be updated again during whatever was happening in the test clock advance.
Trying to think of what to do in that case. That doc's advice of doing an exponential backoff with random jitter may still work here
I will double check but I think our node library has a setting to automatically do this
small shuttle
expo backoff may work.. another thought is to maintain our own queue of failed functions. we're going to perform some connect transfers, so these cannot fail
amber rose
Yeah that totally makes sense as well. Also I was right, you can enable automatic retries by specifying the maximum number of times you would like the library to retry https://github.com/stripe/stripe-node#network-retries
amber rose
Nice! Glad that could help. It is a really helpful feature
lost loomBOT