Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch serenity's ratelimiter to a ratelimiting queue instead of returning a sleep duration #2781

Draft
wants to merge 95 commits into
base: next
Choose a base branch
from

Conversation

tazz4843
Copy link
Contributor

My bot sends large numbers of webhooks concurrently that hit Discord ratelimits quite quickly. Serenity's current implementation has them all fire simultaneously when the ratelimit expires, easily resulting in >10k 429s in under 10 minutes, and the dreaded 1 hour Cloudflare ban. I'm hoping this fixes the issue. Currently untested, opening for review.

@github-actions github-actions bot added the http Related to the `http` module. label Feb 29, 2024
GnomedDev and others added 25 commits March 13, 2024 11:07
…erenity-rs#2646)

This avoids having to allocate to store fixed length (replaced with normal
array) or fixed capacity (replaced with `ArrayVec`) collections as vectors for
the purposes of putting them through the `Request` plumbing.

Slight behavioral change - before, setting `params` to `Some(vec![])`
would still append a question mark to the end of the url. Now, we check
if the params array `is_empty` instead of `is_some`, so the question
mark won't be appended if the params list is empty.

Co-authored-by: Michael Krasnitski <42564254+mkrasnitski@users.noreply.github.com>
These are unnecessary. Accepting `impl Into<Arc<T>>` allows passing either `T` or `Arc<T>`.
This trades a heap allocation for messages sent along with thread
creation for `Message`'s inline size dropping from 1176 bytes to 760
bytes,
…l models (serenity-rs#2656)

This shrinks type sizes by a lot; however, it makes the user experience slightly
different:

- `FixedString` must be converted to String with `.into()` or `.into_string()`
  before it can be pushed to, but dereferences to `&str` as is.
- `FixedArray` must be converted to `Vec` with `.into()` or `.into_vec()`
  before it can be pushed to, but dereferences to `&[T]` as is.

The crate of these types is currently a Git dependency, but this is fine for
the `next` branch. It needs some basic testing, which Serenity is perfect for,
before a release will be made to crates.io.
…enity-rs#2668)

This commit:

- switches from `u64` to `i64` in `CreateCommandOption::min_int_value` and
`CreateCommandOption::max_int_value` to accommodate negative integers in
Discord's integer range (between -2^53 and 2^53). Values outside this
range will cause Discord's API to return an error.
- switches from `i32` to `i64` in `CreateCommandOption::add_int_choice` and
`CreateCommandOption::add_int_choice_localized` to accommodate Discord's
complete integer range (between -2^53 and 2^53). Values outside this
range will cause Discord's API to return an error.
This cache was just duplicating information already present in `Guild::members`
and therefore should be removed.

This saves around 700 MBs for my bot (pre-`FixedString`).

This has to refactor `utils::content_safe` to always take a `Guild` instead
of`Cache`, but in practice it was mostly pulling from the guild cache anyway
and this means it is more likely to respect nicknames and other information,
while losing the ability to clean mentions from DMs, which do not matter.
`Embed::fields` previously had to stay as a `Vec` due to `CreateEmbed` wrapping
around it, but by implementing `Serialize` manually we can overwrite the
`Embed::fields` with a normal `Vec`, for a small performance hit on
serialization while saving some space for all stored `Embed`s.
Simply missed these when finding and replacing.
This uses the `bool_to_bitflags` macro to remove boolean (and optional boolean)
fields from structs and pack them into a bitflags invocation, so a struct with
many bools will only use one or two bytes, instead of a byte per bool as is.

This requires using getters and setters for the boolean fields, which changes
user experience and is hard to document, which is a significant downside, but
is such a nice change and will just become more and more efficient as time goes
on.
…rs#2681)

This swaps fields that store `Option<Int>` for `Option<NonMaxInt>` where the
maximum value would be ludicrous. Since `nonmax` uses `NonZero` internally,
this gives us niche optimisations, so model sizes can drop some more.

I have had to include a workaround for [serenity-rs#17] in `optional_string` by making my
own `TryFrom<u64>`, so that should be removable once that issue is fixed.

[serenity-rs#17]: LPGhatguy/nonmax#17
A couple of clippy bugs have been fixed and I have shrunk model
sizes enough to make `clippy::large_enum_variant` go away.
A discord bot library should not be using the tools reserved for low
level OS interaction/data structure libraries.
Discord seems to internally default Ids to 0, which is a bug whenever
exposed, but this makes ID parsing more resilient. I also took the
liberty to remove the `From<NonZero*>` implementations, to prevent future
headaches, as it was impossible to not break public API as we exposed
`NonZero` in `*Id::parse`.
…nity-rs#2694)

This, 
1. shrinks the size of Request, when copied around, as it doesn't have
to store the max capacity at all times
2. shrinks llvm-lines (compile time metric) for my bot in debug from
`1,153,519` to `1,131,480` as no monomorphisation has to be performed
for `MAX_PARAMS`.
Follow-up to serenity-rs#2694.

When `Request::params` was made into an ArrayVec, the `Option` around it
was removed in order to avoid having to add a turbofish on `None` to
specify the value of `MAX_PARAMS`. Also, `Request::new` also needed to
be changed so that the value of `MAX_PARAMS` could be inferred. Now that
the field is a slice again, we can wrap it in `Option` again (at no cost
to size, thanks to niche opts).

We ensure we never store the redundant `Some(&[])` by checking for an
empty slice and storing `None` instead. This way, we ensure we never
read an empty slice out of the `Some` variant.
The instrument macros generate 2% of Serenity's release mode llvm-lines,
and are proc-macros so hurt compile time in that way, so this limits
them to opt-in. This commit also fixes the issues that the instrument macro
was hiding, such as results that didn't ever error and missing
documentation.
This signature is hard to use as `None` cannot infer the type of the
generic. I also replaced `Option<u8>` with `Option<NonMaxU8>` as it's
more efficient and will make the user think of the maximum value.
arqunis and others added 14 commits March 13, 2024 11:08
`Channel::name` just called `to_channel` (cloning the entire `Channel`!) and
`PrivateChannel::name` or `GuildChannel::name`.

`GuildChannel::name` just returned the field of the same name, for consistency
with `PrivateChannel::name`.

`PrivateChannel::name` returned a non-standard format string that would be very
easy to replicate in user code.

I also tweaked the signature of `OnlineStatus::name` to stop passing an 8 byte
reference to a 1 byte struct, and return `&'static str`.
…serenity-rs#2789)

This also disables the `#[non_exhaustive]` attribute on `FullEvent` if
`unstable` is enabled as a feature. 

It is already expected that any change to Serenity with `unstable` enabled may
or may not break code using this feature and making this enum exhaustive allows
for use cases such as fine-grained audit logging, where new variants should be
a compiler error.

Co-authored-by: Gnome! <david2005thomas@Gmail.com>
@GnomedDev
Copy link
Member

Hey, is this going to be worked on or do you want me to take over this? I'm running into rate limiting issues on prod.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
http Related to the `http` module.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants