What is error code 35, returned by the telegram.org server

Question

My client often receives the following message container from the telegram server, seemingly at random:

{'MessageContainer': [{'msg': {u'bad_msg_notification': {u'bad_msg_seqno': 4, u'bad_msg_id': 6330589643093583872L, u'error_code': 35}}, 'seqno': 4, 'msg_id': 6330589645303624705L}, {'msg': {u'msgs_ack': {u'msg_ids': [6330589643093583872L]}}, 'seqno': 4, 'msg_id': 6330589645303639041L}]})

You may notice: 'error code': 35 above, but there is no description of what that error code means. So far I have been ignoring it but that is not a good long term solution IMHO. Any ideas what that error code means?

Answer 1

There are a set of errors associated with bad_msg_seqno

From the documentation:

Here, error_code can also take on the following values:

32. msg_seqno too low (the server has already received a message with a lower msg_id but with either a higher or an equal and odd seqno)
33. msg_seqno too high (similarly, there is a message with a higher msg_id but with either a lower or an equal and odd seqno)
34. an even msg_seqno expected (irrelevant message), but odd received
35. odd msg_seqno expected (relevant message), but even received

Formal Definition: Message Sequence Number (msg_seqno)

a 32-bit number equal to twice the number of “content-related” messages (those requiring acknowledgment, and in particular those that are not containers) created by the sender prior to this message and subsequently incremented by one if the current message is a content-related message. A container is always generated after its entire contents; therefore, its sequence number is greater than or equal to the sequence numbers of the messages contained in it.

Notes:

1. Every new session starts from seq_no = 1 --> (0 * 2) + 1
2. Every sequence number you send is calculated as: (number_of_content_messages_ already_sent * 2) + 1 hence the all sequence numbers you send are always odd
3. A container messages seq_no == the max seq_no of its content messages
4. The server will always reply you with the correct server_seq_no which should be 1 greater than your correct max seq_no so far.
5. hence a good check / seq_no correction scheme would be to use the latest received server_seq_no (which should always be even) to confirm what your current-expected seq_no should be, and adjust as required.

The above technique has worked for me in avoiding these intermittent error messages completely.