From 68b904e4c71aab774f9a15f7ed4299680659682a Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Wed, 6 Dec 2023 20:26:40 +0000 Subject: [PATCH] Update content of files --- data/web/corefork.telegram.org/api/invoking.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/data/web/corefork.telegram.org/api/invoking.html b/data/web/corefork.telegram.org/api/invoking.html index 90333bfe65..3305b71887 100644 --- a/data/web/corefork.telegram.org/api/invoking.html +++ b/data/web/corefork.telegram.org/api/invoking.html @@ -120,7 +120,7 @@ It may be required to repeat the process if the newly sent invokeAfterMsgs

Obviously the first option (waiting for replies (errors or successes) for all of the queries mentioned before proceeding) is the simplest.

-

An even simpler option is to always follow Scenario 1, never using invokeAfterMsgs and only using chained invokeAfterMsg calls, which avoids the use of this slightly more complicated logic.

+

An even simpler option is to always follow Scenario 1, never using invokeAfterMsgs and only using chained invokeAfterMsg calls, thus avoiding the use of this slightly more complicated recovery logic.

Helper Method Sequence

Important: if the helper methods invokeAfterMsg / invokeAfterMsgs are used together with invokeWithLayerN or other helper methods, invokeAfterMsg / invokeAfterMsgs must always be the outermost wrapper.

Data Compression