* Gateway: Fix Gateway.Open overwriting the context argument
* WSUtil: Remove max context timeout in Websocket.Dial
* WSUtil: Use Websocket.Timeout if a no-deadline context is given to .Dial
* WSUtil: Add doc to Websocket.Timeout clarifying that it must not be changed after use
This change skips events that are unknown while the bot reconnects. This
is an event that is particularly rare as it requires unimplemented
events being called in the time before a bot's HELLO -> RESUME events
are called. This change explicitly returns unknown events as a special
time defined in wsutil/op.go and ignores them from reaching gateway/op.go
* Gateway: Fix gateway reconnect
This commit uses the correct timeout, Gateway.ReconnectTimeout, when reconnecting. Furthermore, it adds a delay between consecutive, failed reconnects.
* Gateway: Stop pacemaker when calling Gateway.CloseGracefully
* API: remove unnecessary leading/trailing whitespaces
* Gateway: Add Gateway.OnScalingRequired callback
* Gateway: Make all user initiated user closures graceful and ensure that closures are respected during reconnects
* Gateway: Fix typo
* Gateway: Add Gateway.ReconnectAttempts and deprecate .ReconnectTimeout
* Gateway: Add Gateway.Pause and reexport .Reconnect and .ReconnectCtx
* Gateway: Improve the Gateway.OnShardingRequired docs
* Wsutil: Code cleanup
This commit modifies Gateway constructors to allow the user to easily
feed existing Identifier instances as well as updating those instances
to adhere to the Discord-returned gateway rate limits.
These changes should make it easier for typical bot sharding, although
automatic sharding is not implemented.
* gateway: add the possibility of graceful closure
* wsutil: rename ConnGracefulCloser to GracefulCloser
* Gateway: rename Gateway.CloseSession to .CloseGracefully
This commit consists of these smaller commits:
Gateway: SessionID to be a method for thread safety
This commit breaks the SessionID field of the Gateway struct to
be thread-safe by wrapping its access with a read-write mutex.
As this is a bug fix, it is reasonable of a breaking change
Heart: Allow later binding of event channel
Voice: Use the new Heart API
Heart: Fixed data races
Heart: Allow changing pace, thread-safe Heartbeat
This commit refactored several structures from package discord to be in
package gateway. Those structures are mostly presence ones, which per
official documentation has a lot more to do with the Gateway API than
the REST API or anything else.
This commit also renamed several global variables to have a more
consistent and obvious name.
As of v8, the user API has had a lot of minor and some major changes,
especially regarding its Ready event API. The most significant change is
the addition of the ReadySupplemental event as well as several changes
to the Ready field itself.
All of these changes above are breaking, and they have already broken
the state package. These breaking changes will be addressed in other
packages by the next commit.
* Gateway: use gateway version 8
* API: remove old v0.0.1 version tag
* Discord: fix typos
* Gateway: add timeout
* Gateway: revert to returning errors on ReconnectCtx
This commit refactors both wsutil, the normal Gateway and the Voice
Gateway to have better closing behavior, which should assume less and
cover edge cases completely.
This commit adds automatic Intents detection into package bot. When the
Start function is used, the intents will be OR'd after running the
options callback.
This commit also breaks the old "AddIntent" methods to rename them to
"AddIntents" for correctness.
This commit fixes race conditions in both package voice, package
voicegateway and package gateway.
Originally, several race conditions exist when both the user's and the
pacemaker's goroutines both want to do several things to the websocket
connection. For example, the user's goroutine could be writing, and the
pacemaker's goroutine could trigger a reconnection. This is racey.
This issue is partially fixed by removing the pacer loop from package
heart and combining the ticker into the event (pacemaker) loop itself.
Technically, a race condition could still be triggered with care, but
the API itself never guaranteed any of those. As events are handled
using an internal loop into a channel, a race condition will not be
triggered just by handling events and writing to the websocket.