sometimes message are not sent.

[asarubbo]

Hello,

I'm running 0.18.0 and I have the following script (taken a bit from the example):

#!/usr/bin/python3.10

from telegram.client import Telegram
import random
chat_id = '12345'
messages = []
messages.append('a')
messages.append('b')
messages.append('c')
message = random.choice(messages)
tg = Telegram(
        api_id="1234",
        api_hash="1234",
        phone="1234",
        database_encryption_key='changeme',
        files_directory='/home/user/.tdlib_files/',
        library_path='/usr/lib64/libtdjson.so'
)

tg.login()
result = tg.get_chats()
result.wait()
if result.error:
     print(f'get chats error: {result.error_info}')

result = tg.send_message(chat_id, message)
result.wait()
if result.error:
     print(f'send message error: {result.error_info}')

So it happens that sometimes message is not sent and for the first time it is sent, all previously undelivered messages are sent.
Practical example:
I run the script at 00:10, the random message is 'a' and it is undelivered
I run the script at 00:15, the random message is 'a' and it is undelivered
I run the script at 00:20, the random message is 'b' and it is undelivered
I run the script at 00:25, the random message is 'c' and I see delivered at the same time: 'a', 'a', 'b', 'c'

I tried with both bundle libtdjson.so and compiled from source libtdjson.so (recent version too), but I have always the same failure.

My guess is that it's not a python-telegram issue but is an upstream libtdjson or service issue. I'm just wondering if I'm the only one that hits this issue and if there is any workaround.

Thanks

[alexander-akhmetov]

Hi! Is this example the entire program you're running for the test? What if you add some sleep after the last line? I suspect that when you receive the response from tdlib (result.wait()), it might mean that your request to send the message was received by the library, but it doesn't necessarily mean that it has been sent.

[asarubbo]

Hi! Is this example the entire program you're running for the test?

Yes, I just changed the content of messages, and obviously replaced the token/auth data

What if you add some sleep after the last line?

I can try, but what would be the difference? I mean I can understand a sleep between result and result.wait or something like that but not at the end.

I suspect that when you receive the response from tdlib (result.wait()), it might mean that your request to send the message was received by the library, but it doesn't necessarily mean that it has been sent.

That's entirely true :D but the question are:

1. Am I the only one that hit this issue?
2. Should I report that to tdlib teams? or there are any tdlib's trick to avoid this issue?

Thanks

[alexander-akhmetov]

That's entirely true :D but the question are:
Am I the only one that hit this issue?
Should I report that to tdlib teams? or there are any tdlib's trick to avoid this issue?

I think this is expected. As far as I understand, the message isn't sent immediately and there are different states, for example: https://core.telegram.org/tdlib/docs/classtd_1_1td__api_1_1message_sending_state_pending.html

Currently python-telegram expects that there is only one response for the call to tdlib. So when you send the message, wait returns as soon as tdlib received the call, but the message isn't sent. I'm not sure yet what exactly happens when the state changes, I'll have a look.

It's also possible to get the message object with get_message method and there should be the sending_state but probably checking each message for it's state is not the best way of confirming that they are sent.

[asarubbo]

It's also possible to get the message object with get_message method and there should be the sending_state but probably checking each message for it's state is not the best way of confirming that they are sent.

I agree that is not the best way but it allows to understand at least why the message has not been delivered.
Is there something implemented in python-telegram that uses get_message ?

[alexander-akhmetov]

Yes, there is a method get_message, but I tried it and it won't work on its own. I found in tdlib issues that messages get temporary ids when you send them, and then tdlib sends updateMessageSendSucceeded event with the old and the new message id that it got from the server.

So actually you need to listen to updateMessageSendSucceeded events to confirm that the message was successfully sent, and you don't need get_message at all. I updated the send_message example, please take a look: https://github.com/alexander-akhmetov/python-telegram/pull/384/files

[dat-browny]

I have a problem that every time I call the example send_message, it didnot send anything, except the first time that i have to input the login code. Can you tell me what problem is? The figure above show that message is sent.

[alexander-akhmetov]

@dat-browny Can you try the new example please?

[asarubbo]

Yes, there is a method get_message, but I tried it and it won't work on its own. I found in tdlib issues that messages get temporary ids when you send them, and then tdlib sends updateMessageSendSucceeded event with the old and the new message id that it got from the server.

So actually you need to listen to updateMessageSendSucceeded events to confirm that the message was successfully sent, and you don't need get_message at all. I updated the send_message example, please take a look: https://github.com/alexander-akhmetov/python-telegram/pull/384/files

Thanks for the update.

I'm not a python programmer but I think there is a mistake.

At some point sent_message_result and message_has_been_sent have been introduced but at the end there is still:

if result.error:
        print(f'Send message error: {result.error_info}')
    else:
        print(f'Message has been sent.')

but result is still initialized to tg.get_chats()

Am I missed something?

In any case I would rename any single result to a related action, like:
result = tg.get_chats() -> result_get_chats = tg.get_chats() and so on

[alexander-akhmetov]

Huh, yes :) I forgot to update it.

In any case I would rename any single result to a related action

Good idea, thanks!

[dat-browny]

@alexander-akhmetov Oh, it work successfully, thank you for solve my problem.

[asarubbo]

I updated the send_message example, please take a look: https://github.com/alexander-akhmetov/python-telegram/pull/384/files

After a bit of test I got into this scenario:

I launched my python script (10:50AM) and the message was immediately delivered. While it was immediately delivered I didn't get the updateMessageSendSucceeded message and the script took ~60 seconds.

After a while I sent another message (11:20AM). It was immediately delivered as well and I got two updateMessageSendSucceeded message. The first was about the first message I sent at 10:50 and the latter was about the message I just sent at 11:20

So I think there is a bit of mismatch between what the API are saying vs the real behavior of a message.

Received updateMessageSendSucceeded: {'@type': 'updateMessageSendSucceeded', 'message': {'@type': 'message', 'id': 209735122944, 'sender_id': {'@type': 'messageSenderUser', 'user_id': XXX}, 'chat_id': XXX, 'is_outgoing': True, 'is_pinned': False, 'can_be_edited': True, 'can_be_forwarded': True, 'can_be_saved': True, 'can_be_deleted_only_for_self': True, 'can_be_deleted_for_all_users': True, 'can_get_added_reactions': False, 'can_get_statistics': False, 'can_get_message_thread': False, 'can_get_viewers': False, 'can_get_media_timestamp_links': False, 'can_report_reactions': False, 'has_timestamped_media': True, 'is_channel_post': False, 'is_topic_message': False, 'contains_unread_mention': False, 'date': 1687423855, 'edit_date': 0, 'unread_reactions': [], 'reply_in_chat_id': 0, 'reply_to_message_id': 0, 'message_thread_id': 0, 'self_destruct_time': 0, 'self_destruct_in': 0.0, 'auto_delete_in': 0.0, 'via_bot_user_id': 0, 'author_signature': '', 'media_album_id': '0', 'restriction_reason': '', 'content': {'@type': 'messageText', 'text': {'@type': 'formattedText', 'text': 'text1', 'entities': []}}}, 'old_message_id': 209718345729}
Received updateMessageSendSucceeded: {'@type': 'updateMessageSendSucceeded', 'message': {'@type': 'message', 'id': 209738268672, 'sender_id': {'@type': 'messageSenderUser', 'user_id': XXX}, 'chat_id': XXX, 'is_outgoing': True, 'is_pinned': False, 'can_be_edited': True, 'can_be_forwarded': True, 'can_be_saved': True, 'can_be_deleted_only_for_self': True, 'can_be_deleted_for_all_users': True, 'can_get_added_reactions': False, 'can_get_statistics': False, 'can_get_message_thread': False, 'can_get_viewers': False, 'can_get_media_timestamp_links': False, 'can_report_reactions': False, 'has_timestamped_media': True, 'is_channel_post': False, 'is_topic_message': False, 'contains_unread_mention': False, 'date': 1687425643, 'edit_date': 0, 'unread_reactions': [], 'reply_in_chat_id': 0, 'reply_to_message_id': 0, 'message_thread_id': 0, 'self_destruct_time': 0, 'self_destruct_in': 0.0, 'auto_delete_in': 0.0, 'via_bot_user_id': 0, 'author_signature': '', 'media_album_id': '0', 'restriction_reason': '', 'content': {'@type': 'messageText', 'text': {'@type': 'formattedText', 'text': text2', 'entities': []}}}, 'old_message_id': 209536942081}

[alexander-akhmetov]

You can try increasing the verbosity of the tdlib logging: Telegram(..., tdlib_verbosity=level) where level is a number (default=2):

Value 0 corresponds to fatal errors, value 1 corresponds to errors, value 2 corresponds to warnings and debug warnings, value 3 corresponds to informational, value 4 corresponds to debug, value 5 corresponds to verbose debug, value greater than 5 and up to 1023 can be used to enable even more logging.

I think tdlib should log these events too, and then maybe we can see if it's an issue in python-telegram. The logging should be useful also because tdlib can send other events too, for example updateMessageSendFailed and there is no handler for it in the example.

[asarubbo]

I tried a more verbose level, but it is really too much verbose. Anyway, given a python script that just sends an hello, if sometimes it does not work, my guess is that the fault is in tdlib. I really doubt that the issue is in python-telegram. We can close for now.