DiscordSocketClient fails to reconnect after Discord API outage #883
Labels
Comments
|
I can confirm that this happened several times to me by now. |
|
I'm aware of this issue and believe I know where the problem is sourcing
from, but it's unfortunately not very easy to diagnose, as I can't easily
reproduce a Discord outage.
…On Nov 17, 2017 19:15, "Łukasz Domeradzki" ***@***.***> wrote:
I can confirm that this happened several times by now to me.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#883 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AMff8hlc2_CyzaqCezZiUA_A-DBjLBYyks5s3iGPgaJpZM4QiyKS>
.
|
foxbot
added a commit
that referenced
this issue
Jan 8, 2018
This resolves #883. The previous behavior when the WebSocket was closed with a 4006 (invalid state) was to kill the reconnect task and log an exception. While this behavior is 'correct', it does not make it obvious to the user (or developer, in my case) as to why their client has just quit and not bothered to attempt a reconnect. The current best way to determine if the client needs to be reset is to check that CloseCode property on the WebSocketException is set to 4006. However, since Discord does not have close code 4006 documented, it feels like only half of a solution. This change allows users to opt-out of fatal invalid-states in the client's configuration - though it is discouraged. If they have not opted out of them, a 4006 will trigger a FatalException, which can then be caught with a more simple pattern match in the Log event. This change also expands what we consider to be a fatal close code, and will raise a FatalException for a 1000 (Discord should never close a connection for us), 4004 (invalid token), 4010/4011 (shard related).
foxbot
added a commit
that referenced
this issue
Jan 27, 2018
This resolves #938 and #883 Note: This fix is not 'verified' in production (I waited over a week for another full Discord outage and never encountered one), but I do have it on record from b1nzy that Discord may send an OP9 with `{"d": true}` during outages, so this would appear to be the proper fix. The removed code seems to have been leftover from when ConnectionManager was rewritten and never finished.
|
Resolved in 73ac9d7 |
FiniteReality
pushed a commit
to FiniteReality/Discord.Net
that referenced
this issue
May 5, 2018
This resolves discord-net#938 and discord-net#883 Note: This fix is not 'verified' in production (I waited over a week for another full Discord outage and never encountered one), but I do have it on record from b1nzy that Discord may send an OP9 with `{"d": true}` during outages, so this would appear to be the proper fix. The removed code seems to have been leftover from when ConnectionManager was rewritten and never finished.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Raspbian GNU/Linux 8.0 (jessie)
.NET Core 2.0
Discord.Net 1.0.2
Discord.Net.Commands 1.0.2
Debug level logs before disconnect
No more logs after these. The client network connectivity was fine.
It seems that the client stops trying to reconnect to the API after disconnect like this. I think the client should persistently attempt to reconnect in all situations.
The text was updated successfully, but these errors were encountered: