MadelineProtoDocs/docs/API_docs/constructors/updates.channelDifferenceTooLong.md

title	description	nav_exclude	image	redirect_from
updates.channelDifferenceTooLong	The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages)	true	https://docs.madelineproto.xyz/favicons/android-chrome-256x256.png	/API_docs/constructors/updates_channelDifferenceTooLong.html

Constructor: updates.channelDifferenceTooLong

Back to constructors index

The provided pts + limit < remote pts. Simply, there are too many updates to be fetched (more than limit), the client has to resolve the update gap in one of the following ways (assuming the existence of a persistent database to locally store messages):

1. Delete all known messages in the chat, begin from scratch by refetching all messages manually with messages.getHistory. It is easy to implement, but suddenly disappearing messages look awful to the user.
2. Save all messages loaded in the memory until application restart, but delete all messages from the database. Messages left in the memory must be lazily updated using calls to messages.getHistory.
   It will look much smoother to the user, they will need to redownload messages only after client restart.
   Unsynchronized messages left in memory shouldn't be saved to the database, results of messages.getHistory and messages.getMessages must be used to update the state of deleted and edited messages left in the memory.
3. Save all messages loaded in the memory and stored in the database without saving that some messages form continuous ranges.
   Messages in the database will be excluded when paginating through or searching the local message history after application restart and will be available only through individual message queries.
   Every message should still be checked using messages.getHistory.
   It has more disadvantages over 2) than advantages.
4. Save all messages with saving all data about continuous message ranges.
   Messages from the database may be used when paginating through or searching the local message history.
   The messages should still be lazily checked using messages.getHistory, but they are still available offline.
   It is the best way for gaps support, but it is pretty hard to implement correctly.

It should be also noted that some messages like live location messages shouldn't be deleted.

Attributes:

Name	Type	Required	Description
final	Bool	Optional	Whether there are more updates that must be fetched (always false)
timeout	int	Optional	Clients are supposed to refetch the channel difference after timeout seconds have elapsed
dialog	Dialog	Yes	Dialog containing the latest PTS that can be used to reset the channel state
messages	Array of Message	Yes	The latest messages
chats	Array of Chat	Yes	Chats from messages
users	Array of User	Yes	Users from messages

Type: updates.ChannelDifference

Example:

$updates_channelDifferenceTooLong = ['_' => 'updates.channelDifferenceTooLong', 'final' => Bool, 'timeout' => int, 'dialog' => Dialog, 'messages' => [Message, Message], 'chats' => [Chat, Chat], 'users' => [User, User]];