From 5e9bb6163f46eb195d95ebc7ce7268ca0a8829c9 Mon Sep 17 00:00:00 2001 From: "Andres G. Aragoneses" Date: Tue, 1 Nov 2016 23:38:28 +0800 Subject: [PATCH] Throw FloodException instead of calling Thread.Sleep() 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). --- README.md | 4 ++-- TLSharp.Core/Network/MtProtoSender.cs | 15 +++++++++++++-- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 1811330..b8e8b11 100644 --- a/README.md +++ b/README.md @@ -211,8 +211,8 @@ TLSharp library should automatically handle these errors. If you see such errors You should create a Telegram session. See [configuration guide](#sending-messages-set-up) -#### Why I get FLOOD_WAIT error? -[It's Telegram restrictions](https://core.telegram.org/api/errors#420-flood) +#### Why do I get a FloodException/FLOOD_WAIT error? +It's likely [Telegram restrictions](https://core.telegram.org/api/errors#420-flood), or a bug in TLSharp (if you feel it's the latter, please open a Github issue). You can know the time to wait by accessing the FloodException::TimeToWait property. #### Why does TLSharp lacks feature XXXX? diff --git a/TLSharp.Core/Network/MtProtoSender.cs b/TLSharp.Core/Network/MtProtoSender.cs index 8929760..9cb7061 100644 --- a/TLSharp.Core/Network/MtProtoSender.cs +++ b/TLSharp.Core/Network/MtProtoSender.cs @@ -272,8 +272,7 @@ namespace TLSharp.Core.Network { var resultString = Regex.Match(errorMessage, @"\d+").Value; var seconds = int.Parse(resultString); - Debug.WriteLine($"Should wait {seconds} sec."); - Thread.Sleep(1000 * seconds); + throw new FloodException(TimeSpan.FromSeconds(seconds)); } else if (errorMessage.StartsWith("PHONE_MIGRATE_")) { @@ -499,6 +498,18 @@ namespace TLSharp.Core.Network } } + public class FloodException : Exception + { + public TimeSpan TimeToWait { get; private set; } + + internal FloodException(TimeSpan timeToWait) + : base($"Flood prevention. Telegram now requires your program to do requests again only after {timeToWait.TotalSeconds} seconds have passed ({nameof(TimeToWait)} property)." + + " If you think the culprit of this problem may lie in TLSharp's implementation, open a Github issue please.") + { + TimeToWait = timeToWait; + } + } + internal abstract class DataCenterMigrationException : Exception { internal int DC { get; private set; }