#cargoinsiten_error
next reefBOT
👋 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/1349467283239604255
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- cargoinsiten_error, 1 hour ago, 3 messages
tough raptor
Hello, do you have the request ID of any of the requests that got this error? I think I can look up by idempotency key but having a request ID too may help
true smelt
- req_oTfEVFYucP26ml
- req_edTlKid0EJGH5W
idempotency key stripe-node-retry-374170df-5a76-478a-8136-01a615e2bf51
tough raptor
So req_2MPpYuwG6ZPZJj is the first request that used that idempotency key. It looks like the request took 12 seconds, and we received those other two calls about 10 seconds after the first one hit. So they were initiated on the client before we responded on the first request. Two ways that I can think of that would happen would be a network timeout, or if you configured your Stripe library to time out after about 10 seconds, in which case the library would have abandoned the calls and retried
next reefBOT
tough raptor
Can you double check if you are setting a timeout in our client library's network settings when you are setting retry behavior and such?
true smelt
we set a 10 second timeout
supple ledge
👋 stepping in as Pompey needs to step away
Taking a look
Yep so looks like my colleague responded with what happened above... the retries occurred due to your timeout before the previous request was finished processing.
So if you are concerned about this you could increase that timeout.
But really this should be very rare (unless you have Invoices with a lot of line items?)
true smelt
hm, yeah it's usually only one line item
according to the error logs in Sentry the first request went at 2:17:00.336 PM UTC, then the next two that failed were at 2:17:00.972 PM and 2:17:01.637 PM. Seems like that's a shorter timespan than the timeout.
is that what you are seeing based on the idempotency key?
I'm having a hard time finding the original request in the developer dashboard since I can't filter by specific times, only dates
supple ledge
That is when the retries occurred.... there was a series of requests prior to that, see: https://dashboard.stripe.com/logs/req_2MPpYuwG6ZPZJj
true smelt
so this first request was made at 2:16:50 PM, then the other three requests were made before the timeout expired? And it retried three times because the retries were failing?
supple ledge
Pretty much
The other two requests using the same idempotency key were 10 seconds later
When the timeout expired
But this request took longer than 10 seconds
Thus the error
true smelt
that makes sense. the invoice tied to the request you linked only has one line item. What explains why the original request took so long?
supple ledge
Hard to say... could just be that the issuer as slow at that moment.
true smelt
okay, thanks for your help and insight. I will take this back to my team and consider increasing that timeout
supple ledge
Ah wait one sec
true smelt
?
supple ledge
You triggered the inital retries here, correct?
true smelt
no
supple ledge
These requests use your secret key... you must have triggered the initial attempt
Not the very first attempt
That failed from the normal renewal attempt
But then these attempts to hit the /pay Invoice endpoint.
true smelt
we make a call to retrieve the invoice and then one to pay the invoice, but we don't have any retry logic implemented.
supple ledge
(Checking something, one sec)
Okay yeah I'm a little confused why there are 5 requests taking place between 2:16:47-2:16:50 that use your secret key. Like there should only be 3 really (your initial request and the 2 retries from the library). I'm seeing that part of the reason the request took so long that led to the timeout is that the Invoice/PaymentIntent was locked up waiting on these previous requests that are taking place at the same time. They also aren't library retries as they have unique idempotency keys.
Are you sure your code isn't running multiple times here?