Was it called once, multiple times, did a network split happened, was it a timeout, is the server side idempotent, was the operator actually performed and only the reply lost, only took too long due to heavy traffic,....?
All timeouts result in exceptions that the client can (or should) handle.
Server side can be made idempotent [1]. And there's a control-plane which acts as the orchestrator [2].
It's possible the operator performed and reply got lost. But if there's insufficient data whether it was actually performed, it can be performed again, unless idempotency [1] was requested.
There _is_ control over the source code from both sides, yes.
> Not everything can be made idempotent.
Can you expand on this, please? I'd appreciate it.
If you mean to say that true idempotence can never be achieved, then you're right [1].
If you mean to say that the framework doesn't allow for the same level of guarantees that other widely used distributed system tools (queues, pub-sub, idempotency key headers) allow, then I'd challenge that notion.
You can use normal code on top of this to solve the bigger problems.