This is done by changing the documentation of the implementations required by interfaces to redirect to the interface method instead (e.g., SocketDMChannel#GetMessagesAsync refer to IMessageChannel.GetMessagesAsync within the remarks of the method).
* Fix incorrect Optional<T> usage
* Indent some sample code and add a comment reminding the user that the post-execution basic sample code is not ideal.
+ Rewritten .NET Core deployment strategies for better clarification
* Split deployment types into framework-dependent and self-contained
* Clarify the benefits of using different types of publishing
* Include a sample of how to execute dotnet application with the dotnet command in a TIP dialog for visibility
+ Add example, remarks for Get(Default)AvatarUrl
+ Add example, remarks for GetOrCreateDMChannelAsync
+ Add missing remarks/summary/returns for other properties of the class
this was done with intention to help keep the repository's working size
down, since most of these files will not be used.
rendered images have been moved online to
https://discord.foxbot.me/logo/
This resolves a bug where disconnecting the socket client would not
actually close the websocket. Bots would appear to remain online in the
discord client until their connection to discord eventually timed out.
The underlying cause of this issue sourced from the cancellation token
passed into the websocket's ReceiveAsync method - when entering the
disconnect process, the first step is to cancel out all of the
connection tokens. Unfortunately, the standard ClientWebSocket handles a
token cancellation by aborting the socket, rendering it inoperable for a
safe closure.
This change removes the inner cancellation token passed into
ReceiveAsync. The cancellation token is still retained for use in the
receive loop, so the receive task should gracefully complete once some
event satisfies the ClientWebSocket's blocking receive.
To ensure that all clients succesfully close, regardless of their
traffic, the disconnect procedure was rearranged such that awaiting the
receive task now occurs last, after the socket has been closed. Closing
the socket will propagate an event up to the ClientWebSocket's receive
method, which will allow the loop to iterate and gracefully complete.
So far, I have validated this change against basic connection opening
and closing, for both the gateway and voice clients. I have not yet
validated against unplanned connection interruptions, though I believe
that this change might actually improve some of those connection bugs,
since the ClientWebSocket should never find itself in an aborted state.
Co-authored-by: Chris Johnston <chris@thejohnstons.net>
commit 23f5abba48
Author: Christopher Felegy <foxbot@protonmail.com>
Date: Thu Dec 20 17:10:21 2018 -0500
lint: clean up some long lines
commit 4a8a809db0
Author: Chris Johnston <chris@thejohnstons.net>
Date: Sat Dec 15 00:33:05 2018 -0800
Explain why CreatorId can be null sometimes
commit 9442e4e635
Author: Chris Johnston <chris@thejohnstons.net>
Date: Fri Dec 14 23:59:01 2018 -0800
Add the CreatorId property to GuildEmote implementation
commit e0eb94d44c
Author: Chris Johnston <chris@thejohnstons.net>
Date: Fri Dec 14 23:41:54 2018 -0800
Update the Emoji API model to add User? attribute