| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
message_update dispatch
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
On certain feature combinations, compilation and tests would not function
correctly.
This commit goes through a number of feature combinations and gates some tests
behind the required features and fixes other compilation errors.
|
| |\| |
|
| | |
| |
| |
| |
| |
| | |
Fix the dispatch functionality potentially deadlocking when a deadlock has
occurred elsewhere (or a read/write lock is forever held elsewhere), and log
when it happens, WARNing the user that a possible deadlock has happened.
|
| |\| |
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the cache is enabled, don't delay the Ready until all guilds have been
received.
This never really worked in the first place and duplicates the "cached" logic
that fires when all guilds have been received.
This presumably fixes the "silent death" bug, as this appears to stall the
thread on certain conditions.
|
| | | |
|
| | |
| |
| |
| |
| | |
Add more `impl From<T> for Game` implementations, and make `Into<Game>` trait
bounds for all function parameters accepting a Game.
|
| | |
| |
| |
| | |
This method won't exist in v0.6.x.
|
| |/ |
|
| |
|
|
|
| |
Some lints were not resolved due to causing API changes. Most lints in the
framework were left unfixed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds an API for message caching. By default this caches 0 messages per
channel.
This can be customized when instantiating:
```rust
use serenity::cache::{Cache, Settings};
let mut settings = Settings::new();
// Cache 10 messages per channel.
settings.max_messages(10);
let cache = Cache::new_with_settings(settings);
```
After instantiation:
```rust
use serenity::cache::Cache;
let mut cache = Cache::new();
cache.settings_mut().max_messages(10);
```
And during runtime through the global cache:
```rust
use serenity::CACHE;
CACHE.write().settings_mut().max_messages(10);
```
|
| | |
|
| |
|
|
|
| |
Fixes links to the repo from `https://github.com/zeyla/serenity` to
`https://github.com/serenity-rs/serenity`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Fixes panics for Guild Member Update dispatches, a retrieval for the
new version of the member sooner and checking that the member exists
prior to dispatching.
Closes #264.
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 062ea86d5b0d9932207636d4a44a5357b079e79a.
This change had the unintended side-effect of making tests with the
Client impossible without hitting Discord's REST API for every test
(even worse, while unauthorized).
Knowing the user's ID on creation isn't _too_ important, and what was
being done with that knowledge can be deferred to connection start.
|
| |
|
|
|
|
| |
Instead of creating different `new` functions for every bridged feature
combination, accept a struct of options. Structs can have conditional
fields, unlike functions which can not have conditional arguments.
|
| |
|
|
|
| |
Add the user ID to the client. This can be used when initializing the
framework on connection start, as well as the future voice manager.
|
| |
|
|
|
| |
The framework no longer needs the `is_bot` boolean state, since serenity
now only supports bot users.
|
| |
|
|
| |
This also fixes no-builder compilation
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Add an event in the EventHandler to be called when a shard updates its
Connection Stage.
|
| |
|
|
|
|
| |
This exposes a method of retrieving a shard's status and latency through
the Shard Manager, as part of the existing Shard Runner Info struct. The
Shard Runner will update this whenever it notices a change.
|
| |
|
|
|
|
| |
By negating hashing altogether.
The increase is around 1000-ish nanoseconds saved.
|
| | |
|
| |
|
|
|
| |
Trims the token given as an argument in Client::new, which will strip
away whitespace that might occur due to including the token from a file.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Fix clippy lints and subsequently accept references for more function
parameters.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the ShardQueuer fails to restart a shard (such as due to a network
error, an issue on Discord's side, Cloudflare, etc.), it will now push
the ID onto a queue.
Every 5 seconds messages will attempt to be read from the receiver, and
if one is not read after the timeout, a queued shard start will occur
(if one is queued).
This should fix a number of reconnection issues.
|