Receiving an event does not establish complete state
Telegram uses state such as pts, qts and seq to check update continuity. Rules differ between streams; gaps require the appropriate difference method rather than a shared cursor for channel and ordinary updates. New events can arrive during recovery, requiring coordinated buffering and merging. Consult Working with Updates for the full algorithm.
Recommended processing boundaries
Separate event reception, durable state changes and product notifications. Commit business data and its processed cursor in one transaction; mark the work complete only after that commit. Give external side effects their own idempotency identifier.
A support message may reach a handler twice without creating two notifications. Edits and deletions also need distinct handling instead of being appended as new messages.
Verify recovery, not merely successful responses
With an isolated test account, exercise brief disconnects, duplicate events, interruption during difference recovery, process restart and simultaneous channel activity. Compare the final state with the expected messages.
When using TDLib, consume its update model rather than layering an unverified raw-MTProto recovery implementation on top.