Different from how usually an IM would work, EFB Telegram Master channel (ETM) strongly rely on Telegram Bot platform. This had made ETM more difficult to deal with messages failed to deliver.
This article is first published on ETM Wiki on 20 April, 2019.
Below is a simplified flow of message delivery in a generic IM.
1.1.1. Deliver message
If the client failed to send a message to the server, it would keep the message locally and retry when possible, until a receipt is received from the server.
In the case where the server received the message but the receipt is failed to deliver back, the client would continue to try sending the message to server. But since the server keeps a record of all messages with their ID, it could simply identify the request as duplicate, drop it, and redeliver the receipt.
Malformed message content can be detected, and rejected by the server, which can be reflected on the receipt. The client can know that the message is rejected and prompt user to try resend.
Similar to 1.1.1., a receipt-based mechanism can be implemented to notifications as well. Even if the notification is delivered without receipt, and missed, the user may still open the app and see the message when message queues are refreshed.
This is always a stable step. Similar to an HTTP GET request, it can always retry the request until getting what it wants. Parameters like “last message ID” can be used to minimize the data of content during retries.
Below is a simplified workflow of ETM message delivery.
2.1.1. Receive message
Due to the limitation of Telegram Bot API, each message can only be retrieved once. There are no way to request for past messages. Therefore, in some cases, ETM might not even know if a message came, despite the user may see the message has been “successfully sent”.
In the case that ETM has to reject message, it can only inform the user by replying the user with a new message informing the failure of delivery. (see 2.2.3 for failure case)
The message might not be delivered due to multiple reasons, probably due to rejection of middleware, slave channel, or failure of delivery to the remote IM. When ETM detects such exception, it will try to inform the user via a reply. (see 2.2.3 for failure case)
As this portion should be taken care by the framework, middlewares and slave channels, ETM would not, and should not be aware of any missing messages.
This is just listed here for completeness.
Usually when an unsupported message is received by ETM, it would be delivered in the fallback form (text message) to the user. Thus there should not be any error occuring on this stage.
This is another crucial scenario in the entire message process. It is (almost) the only way that ETM can pass information to the user. However, ETM cannot do much on this situation other than just retry.
In general, the main problem of message delivery for a master channel rely on Telegram Bot API is that:
Your email address will not be published. Required fields are marked *
Notify me of follow-up comments by email.
Notify me of new posts by email.