1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
// Copyright 2020 - developers of the `grammers` project.
//
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
// https://www.apache.org/licenses/LICENSE-2.0> or the MIT license
// <LICENSE-MIT or https://opensource.org/licenses/MIT>, at your
// option. This file may not be copied, modified, or distributed
// except according to those terms.
use grammers_tl_types as tl;
use ;
use ;
/// Telegram sends `seq` equal to `0` when "it doesn't matter", so we use that value too.
pub const NO_SEQ: i32 = 0;
// See https://core.telegram.org/method/updates.getChannelDifference.
pub const BOT_CHANNEL_DIFF_LIMIT: i32 = 100000;
pub const USER_CHANNEL_DIFF_LIMIT: i32 = 100;
// > It may be useful to wait up to 0.5 seconds
pub const POSSIBLE_GAP_TIMEOUT: Duration = from_millis;
/// After how long without updates the client will "timeout".
///
/// When this timeout occurs, the client will attempt to fetch updates by itself, ignoring all the
/// updates that arrive in the meantime. After all updates are fetched when this happens, the
/// client will resume normal operation, and the timeout will reset.
///
/// Documentation recommends 15 minutes without updates (https://core.telegram.org/api/updates).
pub const NO_UPDATES_TIMEOUT: Duration = from_secs;
/// A [`MessageBox`] entry key.
pub
/// Represents a "message box" (event `pts` for a specific entry).
///
/// See <https://core.telegram.org/api/updates#message-related-event-sequences>.
/// Represents the information needed to correctly handle a specific `tl::enums::Update`.
pub
/// The state of a particular entry in the message box.
pub
// > ### Recovering gaps
// > […] Manually obtaining updates is also required in the following situations:
// > • Loss of sync: a gap was found in `seq` / `pts` / `qts` (as described above).
// > It may be useful to wait up to 0.5 seconds in this situation and abort the sync in case a new update
// > arrives, that fills the gap.
//
// This is really easy to trigger by spamming messages in a channel (with as little as 3 members works), because
// the updates produced by the RPC request take a while to arrive (whereas the read update comes faster alone).
pub
;
pub