Is this a typical definition of idempotency? One where you have to be idempotent even when another system is in play? I wouldn't expect anything to be idempotent if something else can come along and change arbitrary state.
No, it is not. Typically an operation is considered idempotent if you can perform it multiple times in a row, with no other intervening operations, and the result is the same as if you had only performed the operation once. I don't know what this person is trying to get at.
> An HTTP method is idempotent if an identical request can be made once or several times in a row with the same effect while leaving the server in the same state.
Which is according to what OP wrote.
I wouldn't translate this into "the intended effect happens at most once", as that behavior includes the effect of the transport. "at most once", "at least once" and "exactly once" are messaging behaviors after all, and idempotency is a method to convert an "at least once"-messaging-effect into an "exactly once"-change-effect.
Faux idempotency exists, but this blog post does not illustrate it.
The post-condition of "touch file.txt" is to "make sure that file.txt exists and is writeable by user". As long as the command succeeds, that post-condition will be true. This makes command idempotent.
Note that a bad permission, FS errors, or even running out of disk space will cause the command to fail. This is fine, idempotency talks about what happens if operation was applied. If it could not be applied, no promises are made.
Yes, ">>" is generally not idempotent except some circumstances. You can make an idempotent system out of it, but you have to be careful. Nothing "faux" there.
The same rules deal with limited resources -- there are no guarantees your tests may run, only that if they do run, they run in identical way.
It can also be implemented as a pure function without side-effects if you provide current time as a query parameter.
Reliable communication over the network and availability issues are different concerns.
Though request idempotency can help with retries for command/mutations.
Queries are usually nullipotent, so they're can be simply retried.
