#GiGStartr - lock_timeout
1 messages · Page 1 of 1 (latest)
Do you have the request ID (req_123 ) where you got this lock timeout error?
GiGStartr - lock_timeout
ypu - in retrospect it isn't really unexpected:
req_WcWpdpy9gH6YHk
the request that locked it is req_Rbx8moYsR7lc1c
I don't think the idempotency key would be related to the timeout. lock_timeout should just be from concurrent requests on the object.
Also if you have not seen it, the node library you are using has a setting for these retries https://stripe.com/docs/rate-limits#object-lock-timeouts
Yup, was aware of it, hence my concurrency pool & rate limit. What wasn't clear is that two separate charges both try to lock the customer record, hence cannot operate in parallel
I was hoping the idempotency key would mark the charges a distinct, hence allow for parallelism. That isn't the case, so I'll add another layer to "chain" or other wise defer multiple charges to a single customer.
As I said, not a problem I can't solve, just a possibly subtle condition