It seems that after triggering a FloodException, and waiting the required time
to be able to use Telegram again, TLSharp throws an exception. I include the
way to reproduce this bug as an [Ignore]d test with the hope that someone
may help me fix the problem soon.
For reference, the whole stacktrace of the exception was:
Test Name: FloodExceptionShouldNotCauseCannotReadPackageLengthError
Test FullName: TLSharp.Tests.TLSharpTestsVS.FloodExceptionShouldNotCauseCannotReadPackageLengthError
Test Source: D:\Projects\GitHub\TLSharp\TLSharp.Tests.VS\TLSharpTestsVs.cs : line 72
Test Outcome: Failed
Test Duration: 0:04:30.7467012
Result StackTrace:
at TLSharp.Core.Network.TcpTransport.<Receieve>d__4.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Core\Network\TcpTransport.cs:line 39
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at TLSharp.Core.Network.MtProtoSender.<Receive>d__9.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Core\Network\MtProtoSender.cs:line 139
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at TLSharp.Core.TelegramClient.<ConnectAsync>d__8.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Core\TelegramClient.cs:line 76
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at TLSharp.Tests.TLSharpTests.<CheckPhones>d__54.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Tests\TLSharpTests.cs:line 329
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at TLSharp.Tests.TLSharpTestsVS.<CheckPhones>d__9.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Tests.VS\TLSharpTestsVs.cs:line 68
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at TLSharp.Tests.TLSharpTests.<FloodExceptionShouldNotCauseCannotReadPackageLengthError>d__55.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Tests\TLSharpTests.cs:line 340
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at TLSharp.Tests.TLSharpTestsVS.<FloodExceptionShouldNotCauseCannotReadPackageLengthError>d__10.MoveNext() in D:\Projects\GitHub\TLSharp\TLSharp.Tests.VS\TLSharpTestsVs.cs:line 73
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
Result Message:
Test method TLSharp.Tests.TLSharpTestsVS.FloodExceptionShouldNotCauseCannotReadPackageLengthError threw exception:
System.InvalidOperationException: Couldn't read the packet length
What's an open source project that cannot be
tested in an open source platform? The best
open source .NET IDE that works in Linux
(MonoDevelop) doesn't have support for
VisualStudio Testing framework, but it has
support for NUnit.
By abstracting a bit the TLSharp.Tests assembly
we can have two different wrappers, one for
NUnit tests and other for VisualStudio tests,
so no one can be left behind.
NumberToAuthenticate works fine for the AuthTest if we put
a "+" before our international prefix when writing the number,
but because this test compares the numbers we got from the
Contacts List with the one in app.config, it could not find it
due to this prefix. Let's rather be prepared for that.
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
