#mattwoberts

1 messages · Page 1 of 1 (latest)

orchid vectorBOT
mighty raven
#

Hi there!

proper drum
#

Hi!

mighty raven
torpid moon
#

boo

proper drum
#

Hi 🙂

torpid moon
#

hi soma, just merging my thread with this one

proper drum
#

Hang on - even if the 500 was caused by a glitch on stripe's side, say a network glitch?

#

Surely not?

torpid moon
#

if you cache 500 responses what's the value of the maxnetworkretries property in the sdk? if it always returns the cached response then retrying is pointless?

proper drum
#

I think there's some misunderstanding - perhaps @mighty raven means that you will get a 500 if the issue is caused by some error caused by your stripe request - something that's not possible? 'Cos if Stripe had an issue, and couldn't service your request, I can't imagine it would cache that response and just serve it up again?

#

ah - actually I've just read that link and it looks like that is the case, the idempotency layuer DOES cache it.... wow.

mighty raven
#

I recommend you to read the link I shared earlier, that covers this https://stripe.com/docs/error-low-level#server-errors

As with user errors, the idempotency layer caches the result of POST mutations that result in server errors (specifically 500s, which are internal server errors), so retrying them with the same idempotency key usually produces the same result.

torpid moon
#

so can you use the sdk to retry forever without using an idempotency key?

proper drum
#

yeah if you don't set a idempotency key it will try again from the looks of it.

#

This is news to me - I'm going to have to go and review my own code!

#

@torpid moon - docs say "Most client libraries can generate idempotency keys and retry requests automatically, but you need to configure it. For finer-grained control over retries, generate idempotency keys and write your own logic for retries."

torpid moon
#

nope, just that video, i was using polly until last night to handle retries. the video said you can set the maxnumberofretries property but it also implies it sets the key too which is not what you'd want

proper drum
#

@torpid moon Ok cool - not really sure I helped here, or if I just got in the way 😉 I'm going to check out my own code though, I'm pretty sure we pulled it out of polly 'cos of the built in retry stuff

torpid moon
#

if you set maxnumberofretries and it sets a key automaticlly but stripe returns a 500 it won't retry as you'd hope

#

so you're better off with polly from my naive understanding

mighty raven
#

I think the MaxNetworkRetries setting will use the same idempotency key when retrying a request.
But in general this is what we recommend when getting a 500 error:

  • Treat requests that return 500 errors as indeterminate
  • Use webhook events to know if the request succeeded or not
proper drum
#

Thanks @mighty raven

torpid moon
#

there's a chance you get a 500 but it worked?

mighty raven
#

there's a chance you get a 500 but it worked?
Correct.

torpid moon
#

🤦‍♂️

mighty raven
#

Again, all of this is covered in the link I shared earlier https://stripe.com/docs/error-low-level#server-errors

You should treat the result of a 500 request as indeterminate. The most likely time to observe one is during a production incident, and generally during such an incident’s remediation Stripe engineers examine failed requests and try to appropriately reconcile the results of any mutations that result in 500s.

torpid moon
#

Stripe engineers examine failed requests and try to appropriately reconcile the results of any mutations that result in 500s so your engineers will see the failed request but see then intent of it and try and action it anyway?

#

ie/make a charge request, prod incident, 500 response, engineer sees what the intent was, makes the adjustment on the server, issues a webhook to say it succeeded?

mighty raven
#

ie/make a charge request, prod incident, 500 response, engineer sees what the intent was, makes the adjustment on the server, issues a webhook to say it succeeded?
Yes, exactly, this can happen.

torpid moon
#

hmm, going to have to have a think on this then, i would rather retry the 500 request until I get a 200 not listen to webhooks to determine if it was a success

mighty raven
#

i would rather retry the 500 request until I get a 200
Unfortunately that's not possible, since retrying the 500 with the same idempotency keys will always return a 500. And if you change the idempotency keys, then you run the risks of successfully doing the same request multiple times in a row.

torpid moon
#

well if there is no key or different keys you see a 500 and then try again until a 200, i don't see how you'd end up with multiple successful requests?

#

500-500-500-200-stop

mighty raven
#

If you retry the same 500 with different API keys, then Stripe could fix the issue later and all the previous 500 will actually be executed correctly.

torpid moon
#

so if i have one request to make a charge of $10 and stripe has a prod issue and i get 3 500 responses and then a 200, you're saying that instead of 1 $10 charge, your engineers will try and fix the failed requests and that 1 customer would be charged $40 instead of $10?

mighty raven
#

Yes, that's why you should use the same idempotency key when retrying a 500 request. This way Stripe know it's the same request and the customer would be only charged $10 once.

torpid moon
#

but in the case of a 500 with the same key we'll always get a 500 right? we'd never get a 200

mighty raven
#

Yes correct.

torpid moon
#

so most devs would try the request again with a new key

#

but you're saying it's best not to retry a 500 because the engineers will fix it on the backend?

rare gulch
#

👋 taking over for my colleague. Let me catch up.

rare gulch
torpid moon
#

hi, above it was mentioned that stripe engineers in the case of a prod incident and clients get 500s will look at the failed requests and try to manually fix the issue and so if a dev sees a 500 and tries 10 times to make the request succeed, and on the 10th request it does succeed the stripe engineers will make a charge 10 times instead of 1

mighty raven
#

but you're saying it's best not to retry a 500 because the engineers will fix it on the backend?
You can retry 500, but with the same idempotency key. Also note that 500 error won't always be fixed, it depends. That's why the doc says to treat them as indeterminate.

torpid moon
#

but there's no point retrying a 500 with the same key as it says it will return the cached response on subsequent requests

quick raft
#

Hey, taking over here. Let me know if there's any follow-up Qs I can answer!

torpid moon
#

I guess just to clarify, that i believe my setup should be to retry over and over any 4xx status codes, not to retry 5xx status codes but check the webhooks to see if something did eventually succeed due to an engineer possibly fixing it. i now have to work out a correlation between failed requests and webhooks and then a timer to know when to manually try again if a stripe engineer didnt fix it

quick raft
#

believe my setup should be to retry over and over any 4xx status codes,
Yes, 4xx are safe to retry as they're a user error

#

Indeed, handling 500 errors is difficult and as such you should treat them as indeterminate and attempt reconciliation via the events that may eventually fire to indicate success/failure

#

Obviously we try to keep these errors to a minimum, but they can/do happen unfortunately and your integration should be prepared for that