#rp
signal creek
analog sandal
Hi there! The cases you linked above makes sense
Looking into the go question, give me a few
digital harness
Thank you!
analog sandal
It looks like the go SDK will retry requests that failed due to a connection error, and will make use of idempotency keys: https://github.com/stripe/stripe-go#automatic-retries
Timeouts are included in this as well
digital harness
If all retries fail, what kind of error would be returned?
The documentation mentions 4 types of errors returned by the go SDK: stripe.ErrorTypeCard, stripe.ErrorTypeAPI, stripe.ErrorTypeIdempotency and stripe.ErrorTypeInvalidRequest. If all retries fail / timeout, does that fall under one of these error types or is that indicated another way?
analog sandal
The go SDK won't return a special error type if all retries are exhausted
digital harness
Gotcha, so it won't be a stripe.Error object at all in that case?
analog sandal
We'll return one of those error types for each request that fails (including retries) but there won't be an additional object that's returned when you reach the max number of retries
digital harness
Hmm I thought all the retries were done transparently by the SDK?
e.g. if I call v, err := stripe.API{}.Invoices.Get(...)
My assumption was that all retries are handled internally by the Get method, and only if they all fail a single error is returned?
analog sandal
Sorry, I'm not a go expert so I recommend testing this out. For example, you can test the behavior for stripe.ErrorTypeCard with one of our test PaymentMethod IDs to simulate a declined payment: https://stripe.com/docs/testing?testing-method=payment-methods#declined-payments
digital harness
Gotcha, thanks! Is there anyone else with more experience with the go SDK that could confirm?
Nvm did some testing and was able to confirm, thanks!
analog sandal
Ah, got it!