This is mainly a half-implemented commit. There are a few more places
where cache consistency is necessary. In the future there will
probably be a member cache policy enum that will be used and cache
consistency will be tackled in part of that larger refactoring.
In order to reduce our amount of backpressure we need to limit the
amount of concurrent chunk requests we can have so the gateway buffer
has some time to breathe.
The previous code would check zombie connections depending on whether
HEARTBEAT_ACK was received. Unfortunately when there's exceeding
backpressure the connection can terminate since the HEARTBEAT_ACK is
buffered very far away despite it being there, just not received yet.
This slows down chunking significantly for bots in a large number of
guilds since it goes down from 75 guilds/request to 1 guild/request.
However the logic was rewritten to fire the chunking request
immediately after receiving the GUILD_CREATE rather than waiting for
all the guilds in the ready stream before doing it.
This is mainly a half-implemented commit. There are a few more places
where cache consistency is necessary. In the future there will
probably be a member cache policy enum that will be used and cache
consistency will be tackled in part of that larger refactoring.
In order to reduce our amount of backpressure we need to limit the
amount of concurrent chunk requests we can have so the gateway buffer
has some time to breathe.
The previous code would check zombie connections depending on whether
HEARTBEAT_ACK was received. Unfortunately when there's exceeding
backpressure the connection can terminate since the HEARTBEAT_ACK is
buffered very far away despite it being there, just not received yet.
This slows down chunking significantly for bots in a large number of
guilds since it goes down from 75 guilds/request to 1 guild/request.
However the logic was rewritten to fire the chunking request
immediately after receiving the GUILD_CREATE rather than waiting for
all the guilds in the ready stream before doing it.
If categories come after a child channel in the dictionary mapping for
whatever reason, then the previous code would remove it from the
mapping and set it to []. This commit aims to fix this.
This seemed to have shaved a few microseconds:
10.8 µs ± 79.6 ns per loop → 8.53 µs ± 48.1 ns per loop
12 µs ± 613 ns per loop → 8.72 µs ± 30.2 ns per loop
With 100K loops each
This should work both on Windows and on Linux.
Apparently these types of blips are considered normal for Discord. So
rather than letting the reconnect logic handler expect these to be
catastrophic, it should handle it specially so it doesn't waste an
IDENTIFY for what ultimately should just be a small networking blip.
This also makes it less noisy for the end-user as these complaints
happen from time to time.
Previously if a disconnect happened the client would get in a bad state
and certain shards would be double sending due to unhandled exceptions
raising back to Client.connect and causing all shards to be reconnected
again.
This new code overrides Client.connect to have more finer control and
allow each individual shard to maintain its own reconnect loop and then
serially request reconnection to ensure that IDENTIFYs are not
overlapping.
This uses the nonce field to properly disambiguate queries. There's
also some redesigning going on behind the scenes and minor clean-up.
Originally I planned on working on this more to account for the more
widespread chunking changes planned for gateway v7 but I realized that
this would indiscriminately slow down everyone else who isn't planning
on working with intents for now.
I will work on the larger chunking changes in the future, should time
allow for it.
Rapptz