| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
A warning message by the Shard stated that the "Heartbeat [is] off",
when it's actually the sequence that is off.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a timeout on new connections of 15 seconds. If 15 seconds comes and
no heartbeat interval has yet been received (indicating a lack of a
Hello message being received), then the shard will indicate that it is
in a failed state and needs to be restarted.
If a Hello is received but the handshake is not further completed to a
Ready stage, then a heartbeat acknowledgement check will clean up the
shard and indicate its failed status.
|
| |
|
|
|
| |
If a heartbeat acknowledgement is not received, then the shard should
restart.
|
| |
|
|
|
| |
Fix broken links caused by the `model` module changes in v0.5.0, which
split up the module into sub-modules for better organization.
|
| | |
|
| |
|
|
|
|
|
| |
Instead of communicating over the gateway in a split form of a
`serde_json::Value` or a `client::bridge::gateway::ShardClientMessage`,
wrap them both into a single enum for better interaction between the
client, gateway, and voice modules.
|
| |
|
|
|
|
|
| |
When calculating the latency between when a heartbeat was sent and a
heartbeat acknowledgement was received, ensure that the heartbeat
acknowledgement was received after the heartbeat was sent. This avoids a
panic. Otherwise, return None.
|
| |
|
|
| |
Implement `Display` and derive `Hash` on `gateway::ConnectionStage`.
|
| |
|
|
|
|
|
|
|
|
| |
Fix shards by taking away their responsibility to re-identify, instead
shutting down shard runners and going through the shard queuer to
restart a shard runner and its associated shard.
This fixes the case where a running shard's session invalidates and
re-IDENTIFYs within 5 seconds before queued shard starts, causing a
cascading failure of sessions for new shards.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `model` module has historically been one giant module re-exporting
all of the model types, which is somewhere around 100 types. This can be
a lot to look at for a new user and somewhat overwhelming, especially
with a large number of fine-grained imports from the module.
The module is now neatly split up into submodules, mostly like it has
been internally since the early versions of the library. The submodules
are:
- application
- channel
- error
- event
- gateway
- guild
- id
- invite
- misc
- permissions
- prelude
- user
- voice
- webhook
Each submodule contains types that are "owned" by the module. For
example, the `guild` submodule contains, but not limited to, Emoji,
AuditLogsEntry, Role, and Member. `channel` contains, but not limited
to, Attachment, Embed, Message, and Reaction.
Upgrade path:
Instead of glob importing the models via `use serenity::model::*;`,
instead glob import via the prelude:
```rust
use serenity::model::prelude::*;
```
Instead of importing from the root model module:
```rust
use serenity::model::{Guild, Message, OnlineStatus, Role, User};
```
instead import from the submodules like so:
```rust
use serenity::model::channel::Message;
use serenity::model::guild::{Guild, Role};
use serenity::model::user::{OnlineStatus, User};
```
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| | |
The names of environment variable tokens in the examples differed, so
this makes them all use the same name.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the shard shutdown via the Context. This works by setting a
"shutdown" field on the Shard struct as being true, indicating that the
Shard has shutdown. The Shard Runner detects this and requests a
shutdown from the Shard Manager.
The ideal solution here would be to add a "Shutdown" variant to
serenity::gateway::ConnectionStage, but that would be a breaking change,
so we instead need to opt for adding a new struct to gateway::Shard.
The Shard Manager has also been updated to only attempt the shutdown of
a shard if it doesn't already know for certain that it shut itself down,
which avoids an error logged saying that there was an error sending a
shutdown message to its Shard Runner.
When all shards have been shutdown (for most bots, this will only be
one), the Shard Manager will end and the Client will stop its
operations, returning thread control to the user.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit is a rewrite of the client module's internals and the
gateway.
The main benefit of this is that there is either 0 or 1 lock retrievals
per event received, and the ability to utilize the ShardManager both
internally and in userland code has been improved.
The primary rework is in the `serenity::client` module, which now
includes a few more structures, some changes to existing ones, and more
functionality (such as to the `ShardManager`).
The two notable additions to the client-gateway bridge are the
`ShardMessenger` and `ShardManagerMonitor`.
The `ShardMessenger` is a simple-to-use interface for users to use to
interact with shards. The user is given one of these in the
`serenity::client::Context` in dispatches to the
`serenity::client::EventHandler`. This can be used for updating the
presence of a shard, sending a guild chunk message, or sending a user's
defined WebSocket message.
The `ShardManagerMonitor` is a loop run in its own thread, potentially
the main thread, that is responsible for receiving messages over an mpsc
channel on what to do with shards via the `ShardManager`. For example,
it will receive a message to shutdown a single shard, restart a single
shard, or shutdown the entire thing.
Users, in most applications, will not interact with the
`ShardManagerMonitor`. Users using the `serenity::client::Client`
interact with only the `ShardMessenger`.
The `ShardManager` is now usable by the user and is available to them,
and contains public functions for shutdowns, initializations, restarts,
and complete shutdowns of shards. It contains utility functions like
determining whether the `ShardManager` is responsible for a shard of a
given ID and the IDs of shards currently active (having an associated
`ShardRunner`). It can be found on
`serenity::client::Client::shard_manager`.
Speaking of the `ShardRunner`, it no longer owns a clone of an Arc to
its assigned `serenity::gateway::Shard`. It now completely owns the
Shard. This means that in order to open the shard, a `ShardRunner` no
longer has to repeatedly retrieve a lock to it. This reduces the number
of lock retrievals per event dispatching cycle from 3 or 4 depending on
event type to 0 or 1 depending on whether it's a message create _and_ if
the framework is in use. To interact with the Shard, one must now go
through the previously mentioned `ShardMessenger`, which the
`ShardRunner` will check for messages from on a loop.
`serenity::client::Context` is now slightly different. Instead of the
`shard` field being `Arc<Mutex<Shard>>`, it is an instance of a
`ShardMessenger`. The interface is the same (minus losing some
Shard-specific methods like `latency`), and `Context`'s shortcuts still
exist (like `Context::online` or `Context::set_game`). It now
additionally includes a `Context::shard_id` field which is a u64
containing the ID of the shard that the event was dispatched from.
`serenity::client::Client` has one changed field name, one field that is
now public, and a new field. `Client::shard_runners` is now
`Client::shard_manager` of type `Arc<Mutex<ShardManager>>`. The
`Client::token` field is now public. This can, for example, be mutated
on token resets if you know what you're doing. `Client::ws_uri` is new
and contains the URI for shards to use when connecting to the gateway.
Otherwise, the Client's usage is unchanged.
`serenity::gateway::Shard` has a couple of minor changes and many more
public methods and fields. The `autoreconnect`, `check_heartbeat`,
`handle_event`, `heartbeat`, `identify`, `initialize`, `reset`,
`resume`, `reconnect`, and `update_presence` methods are now public. The
`token` structfield is now public. There are new getters for various
structfields, such as `heartbeat_instants` and `last_heartbeat_ack`.
The breaking change on the `Shard` is that `Shard::handle_event` now
takes an event by reference and, instead of returning
`Result<Option<Event>>`, it now returns `Result<Option<ShardAction>>`.
`serenity::gateway::ShardAction` is a light enum determining an action
that someone _should_/_must_ perform on the shard, e.g. reconnecting or
identifying. This is determined by `Shard::handle_event`.
In total, there aren't too many breaking changes that most of userland
use cases has to deal with -- at most, changing some usage of `Context`.
Retrieving information like a Shard's latency is currently not possible
anymore but work will be done to make this functionality available
again.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The client now returns a Result in preparation of a future commit.
Upgrade path:
Handle the case of an error via pattern matching, or unwrap the Result.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| | |
* If a guild's emojis are being altered, Serenity will straight up use the new `HashMap` instead of just extending.
If `connect()` returns an `Err`, it will retry connecting.
Cleaned up `help_command.rs`.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes shard connections by removing the Default implementation for
Shards.
This was because when instantiating a Shard, `..Default::default()`
syntax was used, which calls the `Default` implementation of the struct
and moves the necessary values over to the overlying instantiation.
When using `..Default::default()` syntax, all values in the Default
implementation are instantiated, even ones that could be deemed
unnecessary.
For example, in the following sample code:
```rust
struct Foo {
x: bool,
y: bool,
}
impl Default for Foo {
fn default() -> Self {
Self {
x: true,
y: true,
}
}
}
// ...
let foo = Foo {
x: false,
..Default::default()
};
```
`Foo::x` will still be instantiated in the Default implementation
despite a value being set in the user's instantiation of Foo.
This causes WebSocket client instantiation to be invalid in the Default
instantiation, because the WebSocket instantiated has no base URL,
causing an error to be returned.
This commit resolves this issue by simply not having a Default
implementation - due to the fact that a default implementation will
never be valid and successful - and instead set all values in
`Shard::new`.
Notes: This issue surfaced with commit
fcc4e2ce2e523248ed33c9f4853d3485cbc9b6e6 (PR #195).
Closes #203.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a resume is received, the heartbeat state would not be reset.
This state includes:
- whether the last heartbeat was acknowledged
- when the last heartbeat was sent
- when the last heartbeat acknowledgement was received
This resulted in the bot re-IDENTIFYing after a Resumed event was
received. To fix this issue, reset them when a Resumed event is
received.
|
| | | |
|
| | |
| |
| | |
Fixes #174
|
| | | |
|
| | |
| |
| |
| | |
Since it's a fairly simple enum. Also changed `is_connecting` to be more idiomatic.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improve shard logic by more cleanly differentiating when resuming, as
well as actually fixing resume logic.
For shard runners, better handling of dead clients is added, as well as
more use of the shard manager, in that the runner will now more
liberally request a restart when required (instead of sitting and doing
nothing infinitely).
|
| | | |
|
| | |
| |
| |
| |
| | |
It was voted that the `on_` prefix is unnecessary, so these have been
dropped.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Switch to the `parking_lot` crate's implementations of
`std::sync::Mutex` and `std::sync::RwLock`, which are more efficient.
A writeup on why `parking_lot` is more efficient can be read here:
<https://github.com/Amanieu/parking_lot>
Upgrade path:
Modify `mutex.lock().unwrap()` usage to `mutex.lock()` (not needing to
unwrap or handle a result), and
`rwlock.read().unwrap()`/`rwlock.write().unwrap()` usage to
`rwlock.read()` and `rwlock.write()`.
For example, modify:
```rust
use serenity::CACHE;
println!("{}", CACHE.read().unwrap().user.id);
```
to:
```rust
use serenity::CACHE;
println!("{}", CACHE.read().user.id);
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Session invalidations include whether the session may be resumable.
Previously, this was not parsed by serenity. This data is now contained
in `GatewayEvent::InvalidateSession` as a boolean, which constitutes a
breaking change for users that manually handle gateway events.
Upgrade path:
Instead of pattern matching on simply the variant like so:
```rust
use serenity::model::event::GatewayEvent;
match gateway_event {
GatewayEvent::InvalidateSession => {
// work here
},
// other matching arms here
_ => {},
}
```
Instead pattern match it as a single field tuple-struct:
```rust
use serenity::model::event::GatewayEvent;
match gateway_event {
GatewayEvent::InvalidateSession(resumable) => {
// work here
},
// other matching arms here
_ => {},
}
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a resume is received, the heartbeat state would not be reset.
This state includes:
- whether the last heartbeat was acknowledged
- when the last heartbeat was sent
- when the last heartbeat acknowledgement was received
This resulted in the bot re-IDENTIFYing after a Resumed event was
received. To fix this issue, reset them when a Resumed event is
received.
|
| | | |
|
| | |
| |
| | |
Fixes #174
|
| | | |
|
| | |
| |
| |
| | |
Since it's a fairly simple enum. Also changed `is_connecting` to be more idiomatic.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Improve shard logic by more cleanly differentiating when resuming, as
well as actually fixing resume logic.
For shard runners, better handling of dead clients is added, as well as
more use of the shard manager, in that the runner will now more
liberally request a restart when required (instead of sitting and doing
nothing infinitely).
|
| |/ |
|
| |
|
|
| |
The shard manager will queue up shards for booting.
|
| | |
|
| | |
|
| | |
|