@@ -10,3 +10,70 @@ You can consider the following:
1010- Use shorter non-asynchronous processing loops.
1111- Use ``asyncio.sleep() `` instead of ``time.sleep() ``.
1212- Use a stable network connection.
13+
14+ Connection recovery
15+ -------------------
16+
17+ Hydrogram coordinates recovery through one task per MTProto session. A closed
18+ transport, connection reset, failed write, request timeout, or missing ping reply
19+ starts recovery. Concurrent requests wait for that same task. Recovery preserves
20+ the authorization key and never logs out, revokes a session, or deletes a session
21+ file.
22+
23+ Connection attempts use exponential backoff with jitter. The session allows five
24+ consecutive initialization attempts, including connections that fail again within
25+ 30 seconds. Backoff starts between 0.5 and 1 second, doubles between attempts, and
26+ is capped at 30 seconds. Each initialization can make up to three transport
27+ connection attempts. A connection that remains healthy for 30 seconds restores the
28+ recovery budget. Exhaustion leaves the session in the ``failed `` state and raises
29+ ``ConnectionError `` to callers. Further RPCs fail promptly instead of silently
30+ starting another unlimited retry loop; an explicit session start or client
31+ reconnection is needed to try again.
32+
33+ A lack of updates is normal for an idle client. Periodic pings require a pong and
34+ provide the transport liveness check. The update watchdog can probe update state
35+ after an idle period, but inactivity alone does not trigger a reconnect.
36+
37+ Request outcomes
38+ ----------------
39+
40+ Requests that have not been sent can proceed after recovery. Requests already
41+ sent either return their available response or fail promptly with
42+ :class: `~hydrogram.errors.ConnectionLostError `, a ``ConnectionError `` subclass.
43+ A request whose response times out raises
44+ :class: `~hydrogram.errors.RequestTimeoutError `, a ``TimeoutError `` subclass.
45+ Both expose ``delivery_uncertain ``: when true, Telegram may have processed the
46+ request. Check its outcome before deciding whether to retry a write operation.
47+ Hydrogram does not automatically replay these requests or RPCs returning server
48+ errors, since repeating an arbitrary method could duplicate side effects.
49+
50+ An explicit bad-server-salt rejection permits a bounded resend with the corrected
51+ salt. Sequence-number errors rebuild only the ephemeral MTProto session and
52+ surface the rejected request to its caller. Authentication failures such as
53+ ``AUTH_KEY_DUPLICATED `` or ``SESSION_REVOKED `` stop recovery and surface the error
54+ without changing stored credentials. Clock-related bad-message errors require
55+ correcting the local clock; they are not retried automatically. Two-factor login
56+ prompts remain available on the current connection.
57+
58+ Connection diagnostics
59+ ----------------------
60+
61+ ``app.connection_health `` returns a snapshot without making a network request:
62+
63+ .. code-block :: python
64+
65+ health = app.connection_health
66+ print (health[" state" ], health[" is_connected" ], health[" last_error" ])
67+
68+ The snapshot contains ``state `` (``stopped ``, ``connecting ``, ``reconnecting ``,
69+ ``connected `` or ``failed ``), ``is_connected ``, ``dc_id ``, ``reconnect_attempt ``,
70+ ``pending_requests ``, ``last_received_at `` and ``last_error ``. The last-received
71+ timestamp includes protocol traffic such as pongs, not just updates.
72+ ``app.is_connected `` continues to describe the client lifecycle; use the health
73+ snapshot to inspect transport readiness during recovery.
74+
75+ The ``hydrogram.session.session `` logger records connection loss, retry delays,
76+ successful recovery, and exhausted attempts. Retry records include ``dc_id ``,
77+ ``connection_state ``, ``reconnect_attempt `` and ``reconnect_delay `` as structured
78+ logging fields. Stopping the client cancels its recovery, ping, receive, update
79+ watchdog, and owned update-processing tasks.
0 commit comments