> On 7 Dec 2020, at 10:58 pm, 'Axel Wagner' via golang-nuts
> wrote:
>
> We recently had the same issue.
>
> On Mon, Dec 7, 2020 at 11:58 AM Gregor Best wrote:
> Hi!
>
> We're using a 3rd party provider's API to handle some of our customer
> requests. Interaction with their API consists of
Thanks for the replies guys. Looks like we (and our provider) will have
to do a bit of soul-searching wrt idempotent API requests. At least it's
good to see that we're not entirely off the beaten path with what we're
doing :)
On 07.12.20 12:58, Axel Wagner wrote:
We recently had the same issu
It's uncommon to talk directly to a server these days, instead, we have
proxies and load balancers along the way as well, and there are many
reasons that a connection would get closed and you'd get an io.EOF. It's
unlikely that the server received the request in this case, but it's
possible, depend
Excellent analysis. Idempotence and exactly once delivery are often glossed
over and yet it is usually critical to proper system design.
The key for me is to remember that the request can fail at ANY point in the
flow.
XA transactions can solve this, but most systems these days rely on eventual
We recently had the same issue.
On Mon, Dec 7, 2020 at 11:58 AM Gregor Best wrote:
> Hi!
>
> We're using a 3rd party provider's API to handle some of our customer
> requests. Interaction with their API consists of essentially POST'ing
> a small XML document to them.
>
> From time to time, `net/
Hi!
We're using a 3rd party provider's API to handle some of our customer
requests. Interaction with their API consists of essentially POST'ing
a small XML document to them.
From time to time, `net/http`'s `Client.Do` returns an `io.EOF`
when sending the request. For now, the provider always rep
