Replies: 4 comments
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 be very surprising to me, my assumption rather is that I'm missing some special PTB exception that has a special meaning.) |
Beta Was this translation helpful? Give feedback.
-
|
I found more details. |
Beta Was this translation helpful? Give feedback.
-
|
I could analyze the occurance a bit more in detail, since I had added better logging in the mean time. It seems that 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? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
For reliable message delivery, I have implemented a FIFO buffer that buffers messages that could not be sent.
It works about like this: append message to FIFO, try to flush FIFO by sending contained messages, and if that fails (exception that signals rate limiting or network errors), try again later. Messages that can be handed to PTB (using
bot.send_message()) without exception are dropped from the FIFO.I am seeing some (only sporadic) weird behavior: sometimes after the TG server has been unreachable, identical copies of messages are flooding the channel. The only explanation I could find is that there are some cases where
bot.send_message()throws an exception, but the message is still delivered to the TG server. In that case my code tries to re-send the message later, leading to numerous duplicate messages being delivered to the server.Is there any such exception raised by PTB that could cause this behavior?
Beta Was this translation helpful? Give feedback.
All reactions