Message delivery issues in EFB Telegram Master channel (comparing to generic IM services)
Tags: ehforwarderbot, telegram, python, chatbot
Published: 2019-12-10 02:46:57

---
title: Message delivery issues in EFB Telegram Master channel (comparing to generic IM services)
published: true
date: 2019-10-31 06:29:20 UTC
tags: EH Forwarder Bot,Telegram,Python,chatbot
canonical_url: https://blog.1a23.com/2019/10/31/message-delivery-issues-in-efb-telegram-master-channel-comparing-to-generic-im-services/
---

Different from how usually an <abbr title="Instant Messaging">IM</abbr> 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](https://github.com/blueset/efb-telegram-master/wiki/Message-delivery-issue-in-ETM-(compare-to-a-generic-IM-service))._

## Dealing errors in a generic IM (example)

Below is a simplified flow of message delivery in a generic IM.

![ETM-0](https://user-images.githubusercontent.com/553831/56454661-bdf9ff80-6397-11e9-8122-18863b9e0622.png)<figcaption>A simplified flow of message delivery in a generic IM</figcaption>

Error could occur in one or more of the following scenarios:

### 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.

### 1.1.2. Verify message content

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.

### 1.2.1. Notify client

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.

### 1.2.2. Retrieve message

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.

## Dealing errors in ETM

Below is a simplified workflow of ETM message delivery.

![ETM-1](https://user-images.githubusercontent.com/553831/56455230-1ed90600-639f-11e9-907e-cecdc999f654.png)<figcaption>A simplified workflow of ETM message delivery</figcaption>

Error could occur in one or more of the following scenarios:

### 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”.

### 2.1.2. Verify and transform message

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)

### 2.1.3. Send message to slave channel

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)

### 2.2.1. Deliver message to ETM

As this portion is 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.

### 2.2.2. Verify and transform

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.

### 2.2.3. Sending message to Telegram (incl. any error messages)

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.

1. **Retry for a fixed number of times**  
This would not work in some cases. As in the case of internet disruption, all of the consecutive requests would fail until giving up, leading to a misdelivery.
2. **Retry indefinitely**  
This would work in some cases. However, some users have reported that the same message was flooded to him when “retry indefinitely” strategy is used. This is potentially caused by incomplete response from the server, which has resulted in a detection of failure, despite the message is successfully sent to the server. Furthermore, there is no API from Telegram that can allow a bot to double-check if a previous message is successfully sent.

* * *

In general, the main problem of message delivery for a master channel rely on Telegram Bot API is that:

1. Client is not informed when ETM has difficulty retrieve message from Telegram
2. Lack of idempotent method of message re-delivery compare to generic IM implementations

The post [Message delivery issues in EFB Telegram Master channel (comparing to generic IM services)](https://blog.1a23.com/2019/10/31/message-delivery-issues-in-efb-telegram-master-channel-comparing-to-generic-im-services/) appeared first on [1A23 Blog](https://blog.1a23.com).