#dannnnnnnnnnnnnnnnnnnnnn_best-practices

1 messages · Page 1 of 1 (latest)

sly cedarBOT
#

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

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

drowsy birch
#

hi there!

soft grail
#

The request ID in question req_w5LjIcpVFwQCNN however it was from the end of May so I can't seem to see it in Stripe to figure out if it is a rate-limited request or a lock timeout

drowsy birch
#

you are using the stripe-python SDK?

soft grail
#

yeah using the stripe-python sdk

drowsy birch
soft grail
#

Yeah which I think still wasn't enough as the transfer that we were trying to create never got created in Stripe.

#

do you think it's best to increase that number? would it ever cause any harm in doing so?

#

oh wait thats hard coded to 2 isn't it - ignore this, I see we can just set it with stripe.max_network_retries

drowsy birch
soft grail
#

do you think the correct solution here is to increase this value? is there ever any way that this could cause things we won't expect to happen?

drowsy birch
#

increasing max_network_retries could negatively impact your rate limits.

#

if we set it to 2 by default, it means its the value we recommend for most integrations.

soft grail
#

and also about it could negatively impact our rate limits, does the max_network_retries not have a drop off like retry after 1 second then 2 then 10 etc?

sly cedarBOT
sage gale
#

Hi 👋

I'm stepping in as my colleague needs to go soon

#

So the problem is you are encountering object locks and looking to identify the best approach?

soft grail
#

hey, yeah either it was a rate limit or object locking, I thought it was a rate limit but after reading your docs apparently it could be either and I can tell by looking at the request. However I can't tell as the request is too old so I don't think I can see it on Stripe. But yeah basically it seems like there are two options, increase that value to something higher than 2 and I was wondering that would fix these scenarios/have any downside or option 2 being that we implement our own retry logic for any 429 responses from Stripe

sage gale
#

We mention here about how the SDK will back off on retires.

soft grail
#

yeah that makes sense, what do you think is the better appraoch to our scenario then?

sage gale
#

It depends on the timeouts you are hitting. It might be worth testing out but if the objects are locked for a significant amount of time, you might still get the same issue.

Do you occasionally get rate limit errors as well?

soft grail
#

nah we have got them like once at the end of May once in March and then before that October 2024 so very rarely. How can we test if objects are locked for significant time?

#

I'm kinda leaning towards it was probably a RateLimit issue rather than an object locking issue just because it came from creating Transfer objects

sage gale
#

Can you share one of the requests where you got a 429 response?

soft grail
#

yeah its above in the chat, its req_w5LjIcpVFwQCNN

sage gale
#

Yeah see that response IS a lock timeout. This means that some other process is in the process of mutating an object that is invovled in this request. It could possibly be the Account object you are trying to send this transfer to.

soft grail
#

oh interesting, is there a way I can see the request through the dashboard cause I can't seem to view it

sage gale
#

The request you just shared with me? Or the request that locked the object?

soft grail
#

the request I shared, if I search for it in the search bar it doesn't seem to come up or am I looking in the wrong place for requests

#

but would also be interesting to know what locked the object too if you know that

sage gale
soft grail
#

oh perfect yeah I can, just wasn't appearing when I use the search bar

#

so is there a way we can figure out what locked the object? is that possible to find out?

sage gale
#

Not directly on your end and only after manual investigation on mine.

soft grail
#

Ok, is that something I can request somehow or are you looking into it at the moment for me?

sage gale
#

I can look it up this one time but it isn't something you can repeatedly request

soft grail
#

Ok perfect thank you so much

sage gale
#

Okay it looks like the account was locked as part of a automatic update being applied. It should've unlocked in less than 1s. Essentially this request just got unlucky.

soft grail
#

sorry for the late reply was on a quick call. So because we've had this occur a few times, is there a good way to prevent this from happening on our end? Like should implement some retry logic then for any 429 responses for scenarios like these?

#

and the automatic update is that something that we started or is that something that Stripe just does occasionally?

sage gale
#

This was something internal, as far as I can tell.

#

And I think building your own retry logic would be a good idea, since the immediate retry that the SDK will use is likely to mean the initial request and first retry will both likely fail

soft grail
#

Ok that sounds good, one last thing from me then. That said back to the whole max_network_retries, if that has a drop off could we not just increase that value to like a 5 or something and would that handle it? If not then yeah we'll implement some retry logic

sage gale
#

It does have an exponential back-off and you can likely achieve what you want by increasing the number of retries but those will count towards your request rate limit.

#

So let's say that you have a request that returns a 429, the immeidate retry returns a 429, and the second retry succeeds

#

There's at least one request there you could do without

#

Of course that is only an issue if you are getting close to hitting rate limits

soft grail
#

Ah ok I see what you're saying. We've never been rate limited so I imagine this would be fine though as in theory our retry logic would just be doing the same thing of wait 1 second try the request again, wait 2 seconds try again etc

sly cedarBOT
soft grail
#

And I guess my other question is if we implement our own retry logic should we be setting that max network retries to 0? That way our own retry system doesn’t interfere with the stripe sdks retry logic/increase our number of requests

pure sage
#

Hi there 👋 jumping in as my teammate needed to step away. Yes, if you're implementing your own retry logic, I'd suggest disabling our automatic retries by setting that value to 0.

soft grail
#

Ok and before I implement this retry logic, just to check does max network retries handle more logic that we might miss with our own logic? Like does it only handle 429 responses or is there more it does?

pure sage
#

There's more to it than that. It also handles situations where no response is received, and it's unclear whether the request reached us and was successful. In those cases we make an idempotent request to safely retry the operation in a way where nothing happens if the previous request was successful.

It's our automatic implementation of the flow we discuss here:
https://docs.stripe.com/api/idempotent_requests

soft grail
#

Ok that's all from me then. Thank you all for your help on the matter, it's much appreciated.