#wabisabi_api
slow parrotBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1243353438494916628
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
elfin gust
Hi there
Sorry looking
That request was a replay of req_CI9aImXzOUUxhd because you used a same idempotency key
And req_CI9aImXzOUUxhd was ran in almost same time with another request which try to add to the same Invoice I think, finding it...
ionic condor
Thank you for taking a look. How long after adding something to the invoice do we have to wait? We've always (for many months) done it serially without waiting. Having to wait seems like new behavior on the Stripe side. Thanks again for taking a look 🙏
elfin gust
req_GmKcg176oIr8i0 req_6tLrYa8MHe54BH which were succeeded, was also trying to add Invoice Item to the same Invoice, as far as I can tell
ionic condor
Serially though
elfin gust
It could depends on the day when internet connection condition changes between your server to Stripe server, so the request came to us in more closer frame
ionic condor
What is the allowed time in between requests?
elfin gust
Yeah agree but they were 2 requests at 18:08:36 and then 1 at 18:08:37
It's hard to say for sure, but I would recommend waiting 3 secs, and implement retry with a new idempotency key
ionic condor
Hmmm we are using the ídem key to ensure we don’t add the same item more than once 😅
elfin gust
The idem key is for when you had a connection error and lost connection with Stripe. If the previous request did reach Stripe and got an error (in this case: lock_timeout) then retrying with idem key will only return the exact original response we gave earlier
In other words, if prev request succeded and the next request also succeded, the idem key helps to dedup. But if the prev request errored, the idem key will make us returns the exact same error
ionic condor
I tried the request manually with same ídem key and it didn’t return a 429 though 🤔
elfin gust
Which request id have you tried? req_CI9aImXzOUUxhd in the question was a replay indeed
ionic condor
req_3NMA0l3gs6VdWi
ah, I must've messed something up when I copied the idem key and retried manually because I tried again with another request and I do see the 429 when I retry it manually
elfin gust
Yeah the Idem key is different. I won't paste it here but I can compare them
ionic condor
we want to be able to do retries on adding items to invoice without adding duplicates
in these cases (for the first time ever) we are getting 429s because of lock_timeout errors which makes it so that we can't retry adding invoice items with idem key as strategy to not add duplicates because we keep getting 429s when using idem key which previously returned 429 😭
maybe all the above is obvious at this point but writing it in case it helps on your end
haha
elfin gust
Yeah thanks! Np
ionic condor
is there a way to have the idem key not return lock_timeout errors? That doesn't make sense to me
maybe it does make sense to do it that way but wondering if you know something I don't and there is a way to configure how the idem key is processed on the stripe side or something
elfin gust
No it's the natural of idem key. When you have got an error before, it will always replay and give you the exact same error
You can think idem key is a way to tell Stripe "continue the work on previous request and return me the result of it". So if it succeded, Stripe will say "okay we have done already, here is the result last time" but if it errored, Stripe will say "we errored, here is the error last time"
There is 1 exception though. When the API request failed before anything happened, we would ignore the idempotency key and act as if it was the first attempt.
An example is if you try to charge a customer that has no card, we return a validation error because there’s no card to charge in the first place. If you then add a card to that customer and retry the request, we would not return the error and instead attempt to charge the card. This behaviour was introduced during the summer 2018