Even if you're not supposed to use multiple threads with TLSharp,
it might be worth it to try to make this sequence increment in
a thread-safe way. Race conditions are always bad even if you know
you are not supposed to use something in a certain way...
@Laituex was having a ErrCode=32 'msg_seqno too low' problem and this
is the first thing we looked at (even if he swore that he was not
using different threads to access the telegram network)
Added CancellationToken with default value to all async methods in TLSharp.Core
Added ConfigureAwait(false) to all async methods in TLSharp.Core
SendRequestAsync replaced to SendAuthenticatedRequestAsync in methods that need auth
Private modifier in SendAuthenticatedRequestAsync changed to internal
Based on PR created by @IaRuslan
It wasn't being used internally, and the use-case to be used
externally is too intricated. There's already a way to change
the handler at contructor time[1] so that should be enough
customization.
[1] 48077961ae
Doing this is better when looking at the problem from at least
these 2 points of view:
a) You're working on TLSharp itself: You might be testing some
new things or running TLSharp's tests. Suddenly, if a FLOOD_WAIT
response happens, there's no clear way to know. You just see the
tests taking forever. But if a test has reached a situation in
which Telegram has returned a FLOOD_WAIT error, it's very likely
that what happens is that the TLSharp operation being tested is
actually buggy, which means that the test should FAIL FAST and
show a stacktrace of the problem so that you can see where in the
code was the FLOOD_WAIT received/caused. You shouldn't need to
kill the run of the test suite and hope to hit the problem again
only when you were using the debugger (to be able to pause
execution and examine a stacktrace of where the execution flow is).
b) You're using TLSharp: if you hit a FLOOD_WAIT problem it may
happen because:
b1) TLSharp has a bug: in this case it's better to throw an
exception so that the user can copy the stacktrace and paste
it into a new Github issue.
b2) Your program uses TLSharp sending excessive requests: you
want to have your program know when you hit the limit, to be
able to fix your program to not be so floody. But a call to
Thread.Sleep() doesn't help you to know this, you just know
that suddenly your program has hung, and you don't know why.
You cannot react to the problem, however with an exception you
can react to the problem (for example by examining the time
that the exception provides, as a TimeSpan property, to know
how much your program needs to wait to be able to use TLSharp
again).
When refactoring recently the PHONE_MIGRATE_X error
wrt exception handling [1] I removed the dubious/obsolete
"settings" part, but I mistakenly removed the URL which
tells library consumers that if they face this exception,
it's actually a bug of the library that they should report.
[1] 77867b44e6
There are different kind of MIGRATE errors that could be
thrown by the Telegram API, as evidenced by this recent
change:
b06f8a8e11
So this rename tries to make it consistent to the new
exception names:
* FILE_MIGRATE_x -> FileMigrationException
* USER_MIGRATE_y -> UserMigrationException
* PHONE_MIGRATE_z -> PhoneMigrationException
Parsing the message of an exception to decide what to do
next is a bad practice, because it's easy that the message
might be changed by mistake in the future. To enforce the
coupling in a stronger way it's better to use exceptions
of different type depending on the kind of error, so that
we rely on the compiler enforcing the behaviour when doing
changes in this error handling areas in the future.
This also makes the code a bit more simple and readable.
Default value of max_id = 0 returns all dialogs
Should return a class with lists of dialog, messages, chats and users.
Add UserForeignConstructor to list of constructors
Add missing detail to DialogConstructor (PeerNotifySettings)
Unpack datastream completely to avoid issue with Ionic exception causing
problems in userForeign parsing
Use more recent code for Dialog construction
