You stumbled upon one of the fundamental problems of networking here. When your request is fully sent out, but the connection breaks before the response reaches you, you will see the read timeout error or smth along the line, but telegram ofc did its expected action.

You can read in the appropriate docs why it is not feasible to hold the confirmation in an unstable connection, but the short answer is: This is how the internet is designed, nothing you can do about it.

Note that "the connection breaks before the response reaches you" doesn't explain the observed behavior here. This would cause a single duplicated message each time the connection drops during sending of the message. But in this case, every send attempt (while the server is claimed to be unreachable), in 5 second steps, delivers (at some point) the message to the TG server, but still raises an exception. 30 messages in a row where the connection broke down exactly mid way during transfer? Unlikely.

My suspicion is that either an exception is raised that does not actually mean "message transfer failed" (I still have to find out which one it is - hard to reproduce...), or that some lower layer caches the messages for later sending, but still causes PTB to report failure via exception.

(On a more general note... of course this fundamental network problem is solvable, and indeed solved. It's the higher ISO layers' task to ensure idempotency... note that we're having this conversion on github - a system that deals with exactly that problem: reliable commits, "all or nothing". If the telegram protocol does not support this, then I'd argue it's broken in that regard. But that would bevery surprising to me, my assumption rather is that I'm missing some special PTB exception that has a special meaning.)

I found more details.
It seems it is linked to this error message:
_updater.py:755 | ERROR | Error while getting Updates: Bad Gateway
Is there any chance this is raised, but the message still gets through to the TG server?

I could analyze the occurance a bit more in detail, since I had added better logging in the mean time.

It seems thatbot.send_message() raises atelegram.error.TimedOut exception. This happens several times in a row, since my code tries attempts to re-send the message. After the TG server is reachable again (after a few minutes, in that specific occurance), a flood of identical messages reaches the TG group. This means the messages did actually get sent, or at least were cached somewhere ... either somewhere in the client stack... or the messages did reach the server, and the TimedOut-Exceptions are wrongly raised.

Is there any way to fix this, i.e. to add an"all or nothing" feature? Does the TG protocol/the PTB framework allow for this?

If no, what is actually the expected way to deal with such cases? There is no way for me to detect in the code whether a message should be re-sent or not. How do (for example) Smartphone clients implement this?