From d1e583cc8640ebcd0a3b69c538908bd206b35493 Mon Sep 17 00:00:00 2001 From: Wizou <11647984+wiz0u@users.noreply.github.com> Date: Thu, 18 May 2023 21:50:19 +0200 Subject: [PATCH] Prevent "You must connect to Telegram first" during network loss (closes #157) --- EXAMPLES.md | 13 ++++++++++--- FAQ.md | 2 +- README.md | 4 ++-- src/Client.cs | 2 +- 4 files changed, 14 insertions(+), 7 deletions(-) diff --git a/EXAMPLES.md b/EXAMPLES.md index 2ffdeae..985d4f9 100644 --- a/EXAMPLES.md +++ b/EXAMPLES.md @@ -491,11 +491,18 @@ A message contains those two fields/properties: - `peer_id`/`Peer` that identify WHERE the message was posted - `from_id`/`From` that identify WHO posted the message (it can be `null` in some case of anonymous posting) -These two fields derive from class `Peer` and can be of type `PeerChat`, `PeerChannel` or `PeerUser` depending on the nature of WHERE & WHO (private chat with a user? message posted BY a channel IN a chat? ...) +These two fields derive from class `Peer` and can be of type `PeerChat`, `PeerChannel` or `PeerUser` depending on the nature of WHERE & WHO +(private chat with a user? message posted BY a channel IN a chat? ...) -The root structure where you obtained the message (typically `UpdatesBase` or `Messages_MessagesBase`) inherits from `IPeerResolver`. This allows you to call `.UserOrChat(peer)` on the root structure, in order to resolve those fields into a `User` class, or a `ChatBase`-derived class (typically `Chat` or `Channel`) which will give you details about the peer, instead of just the ID. +The root structure where you obtained the message (typically `UpdatesBase` or `Messages_MessagesBase`) inherits from `IPeerResolver`. +This allows you to call `.UserOrChat(peer)` on the root structure, in order to resolve those fields into a `User` class, or a `ChatBase`-derived class +(typically `Chat` or `Channel`) which will give you details about the peer, instead of just the ID. -However, in some case _(typically when dealing with updates)_, Telegram might choose to not include details about a peer because it expects you to already know about it (`UserOrChat` returns `null`). That's why you should collect users/chats details each time you're dealing with Updates or other API results inheriting from `IPeerResolver`, and use the collected dictionaries to find details about users/chats ([see previous section](#collect-users-chats) and [Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) example) +However, in some case _(typically when dealing with updates)_, Telegram might choose to not include details about a peer +because it expects you to already know about it (`UserOrChat` returns `null`). +That's why you should collect users/chats details each time you're dealing with Updates or other API results inheriting from `IPeerResolver`, +and use the collected dictionaries to find details about users/chats +([see previous section](#collect-users-chats) and [Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) example) And finally, it may happen that you receive updates of type `UpdateShortMessage` or `UpdateShortChatMessage` with totally unknown peers (even in your collected dictionaries). In this case, [Telegram recommends](https://core.telegram.org/api/updates#recovering-gaps) that you use the [`Updates_GetDifference`](https://corefork.telegram.org/method/updates.getDifference) method to retrieve the full information associated with the short message. diff --git a/FAQ.md b/FAQ.md index 99875b6..63bae26 100644 --- a/FAQ.md +++ b/FAQ.md @@ -205,7 +205,7 @@ You can choose to increase `MaxAutoReconnects` if it happens too often because y 3) If you reach `MaxAutoReconnects` disconnections, then the **OnOther** event handler will receive a `ReactorError` object to notify you of the problem, and pending API calls throw the network IOException. -In this case, the recommended action would be to dispose the client and recreate one +In this case, the recommended action would be to dispose the client and recreate one (see example [Program_ReactorError.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ReactorError.cs)) 4) In case of slow Internet connection or if you break in the debugger for some time, you might also get Connection shutdown because your client couldn't send Pings to Telegram in the allotted time. diff --git a/README.md b/README.md index 655e5b3..04bece6 100644 --- a/README.md +++ b/README.md @@ -161,8 +161,8 @@ See [FAQ #4](https://wiz0u.github.io/WTelegramClient/FAQ#access-hash) to learn m # Other things to know -The Client class also offers `OnUpdate` and `OnOther` events that are triggered when Telegram servers sends Updates (like new messages or status) or other structures, independently of your API requests. -See [Examples/Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) +The Client class also offers `OnUpdate` and `OnOther` events that are triggered when Telegram servers sends Updates (like new messages or status) or other notifications, independently of your API requests. +See [Examples/Program_ListenUpdates.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ListenUpdates.cs?ts=4#L23) and [Examples/Program_ReactorError.cs](https://github.com/wiz0u/WTelegramClient/blob/master/Examples/Program_ReactorError.cs?ts=4#L32) An invalid API request can result in a `RpcException` being raised, reflecting the [error code and status text](https://revgram.github.io/errors.html) of the problem. diff --git a/src/Client.cs b/src/Client.cs index 794a251..dd3835e 100644 --- a/src/Client.cs +++ b/src/Client.cs @@ -198,7 +198,7 @@ namespace WTelegram _reactorTask?.Wait(1000); } catch { } - _reactorTask = null; + _reactorTask = resetSessions ? null : Task.CompletedTask; _networkStream?.Close(); _tcpClient?.Dispose(); #if OBFUSCATION