#kurt85_api

1 messages · Page 1 of 1 (latest)

shy robinBOT
#

👋 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/1285233794164588584

📝 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.

worthy tartanBOT
candid star
#

not sure if this may be a bad use of the library, but we are reusing the same RequestObject instance for these consecutive calls, however it only fails in our staging environment not on single tests:
RequestOption requestOptions = RequestOptions.builder()
.setApiKey(.......).build();
try {
Invoice invoice =
Invoice.create(invoiceCreateParams, requestOptions)
.addLines(addLinesParams, requestOptions)
.finalizeInvoice(finalizeParams, requestOptions);
log.debug("Created an invoice with id: {}", invoice.getId());
this.updatePaymentIntent(invoice, requestOptions);
return invoice;
} catch (StripeException e) {
....

exotic flume
#

Hi there 👋 will need a bit to dig into this, but so far it looks like there is a lock on the Customer object, that is being held by another request to add Invoice Items.

candid star
#

ok, that makes sense, we may be using the same customer id in parallel requests

exotic flume
#

It's actually a little tricky for me to look at this, you're making so many requests for this Customer in a relatively short time period that I'm able to see everything well on my side 😅

#

Is it possible you have multiple staging flows reusing this same Customer that could be cluttering things?

candid star
#

yeah, this error arises when we run our testing suite, and I just confirmed with our QA Engineer that we are using the same customer id, so if you say that the locks are at customer level it makes sense

#

however, we are setting retries as I mentioned in the original message but I don't see it in the dashboard, is it expected?

candid star
exotic flume
#

I'm working on double checking, but I believe automatic request retries only happen if there is a network problem that causes the response to the request to have not been received. The object locks do respond to the request, with an expected status (even if that outcome is unexpected from a process viewpoint).

exotic flume
candid star
#

yes

exotic flume
#

I believe that's fine

candid star
# exotic flume Yeah, intermittent network or other non-deterministic errors. https://github.com...

According to these other docs it should be already covered by the library: https://docs.stripe.com/rate-limits#object-lock-timeouts

Lock timeouts have a different cause than rate limiting, but their mitigations are similar. As with rate limiting errors, we recommend retrying on an exponential backoff schedule (see Handling limiting gracefully). But unlike rate limiting errors, the automatic retry mechanisms built into Stripe’s SDKs retry 429s caused by lock timeouts:

Rate limits

Learn about API rate limits and how to work with them.

#

can you confirm if you can see retries for the same request on your side?

exotic flume
#

Oh, good spot, sorry I forgot about that.

candid star
#

should the retries be visible on the dashboard?

exotic flume
#

Hm, I'm not seeing any retries. I only see one request using that idempotency key.

shy robinBOT
candid star
#

can you see the reponse headers for that request? Only request headers are shown on the dashboard, I don't see the response ones

exotic flume
#

Not quickly, maybe with some digging. Why are you asking about the response headers?

candid star
#

because according to the docs, the library would retry or not depending on the should_retry response header

#

as we don't see retries I want to confirm if it is coming in the response

#

we will also do changes in our test suite to use different customer ids

lone escarp
#

👋 stepping in and catching up

#

So yeah we perform those retries under the hood in this case.

#

You don't see separate API requests for that

#

You basically just handle this end-result.

#

So I can see in our logs that retries did occur based on your retry settings with the SDK

#

But the lock was for too long so it still timed out