#discord #discord-api #twilight


Discord Gateway connection queue implementation for the Twilight ecosystem

11 releases (7 breaking)

0.8.0 Dec 3, 2021
0.7.0 Oct 21, 2021
0.6.0 Jul 31, 2021
0.3.0 Jan 8, 2021
0.2.1 Nov 10, 2020

#355 in Data structures

Download history 222/week @ 2021-09-25 175/week @ 2021-10-02 646/week @ 2021-10-09 314/week @ 2021-10-16 259/week @ 2021-10-23 362/week @ 2021-10-30 498/week @ 2021-11-06 572/week @ 2021-11-13 481/week @ 2021-11-20 653/week @ 2021-11-27 679/week @ 2021-12-04 477/week @ 2021-12-11 713/week @ 2021-12-18 799/week @ 2021-12-25 547/week @ 2022-01-01 383/week @ 2022-01-08

2,471 downloads per month
Used in 7 crates (via twilight-gateway)

ISC license

21K SLoC


Ratelimiting functionality for queueing new gateway sessions.

The gateway ratelimits how often clients can initialize new sessions. Instances of a queue are given to shards so that they can request to initialize a session.

Queue implementations must point to the same broker so that all shards across all clusters, processes, and other forms of multi-serviced applications, can work together and use the same ratelimiting source. That is, if you for example have two clusters in two different processes, then the two processes must use some unified form of ratelimiting: this can either mean using IPC to communicate ratelimiting or a broker.

Provided queues

Most users only need the [LocalQueue]: it's a single-process queue for smaller bots. Larger bots need the [LargeBotQueue], which supports single-process Sharding for Very Large Bots through the use of bucket releasing.

By default, the gateway's Cluster and Shards use the [LocalQueue]. You can override this in the ClusterBuilder::queue and ShardBuilder::queue configuration methods.

Advanced use cases

Large bots, and smaller bots out of design, may need to implement their own queue. The most common reason to need this is if you have clusters in multiple processes. You'll need a broker to manage ratelimiting across them all so a [Queue] trait is provided that shards can use to make requests to create sessions.



The tracing feature enables logging via the [tracing] crate.

This is enabled by default.


~251K SLoC