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.
This prevents our sessions from being invalidated by Discord which
caused a lot of failures when resuming. This caused an unnecessary
amount of IDENTIFYs to happen depending on the circumstances.
Closes#2631
See also discord/discord-api-docs#1472
Probably not a significant difference but might as well use it here.
The basic idea is to cache the getattr calls instead of repeatedly
doing it (since they're around 105ns on my machine). The dictionary
lookup is about 41ns on my machine.
The next step in speeding up library code some more should be in
the parser bodies themselves but that's a problem to tackle another
day.
* type(x) is y is faster than isinstance(x, y)
* Re-arrange if-statements for common statements
* Drop handler getattr for most events that don't use it
This is a massive breaking change.
* All references to "game" have been renamed to "activity"
* Activity objects contain a majority of the rich presence information
* Game and Streaming are subtypes for memory optimisation purposes for
the more common cases.
* Introduce a more specialised read-only type, Spotify, for the
official Spotify integration to make it easier to use.
When accessing the latencies property on an AutoShardedClient when none of shards are ready, we get a ZeroDivisionError. An example of this can be seen here.
```py
class StatsBot(commands.AutoShardedBot):
def __init__(self):
super().__init__(command_prefix=None)
self._add_commands()
def _add_commands(self):
'''Adds commands automatically'''
for name, attr in inspect.getmembers(self):
if isinstance(attr, commands.Command):
self.add_command(attr)
```
When iterating through this custom client's it accesses the latencies property when no shards are ready, therefore it raises the error. A quick fix for this would be to return None if no shards are ready.
This time with less bugs. It turned out that the crash was due to a
synchronisation issue between the pending reads and the actual shard
polling mechanism.
Essentially the pending reads would be cancelled via a simple bool but
there would still be a pass left and thus we would have a single
pending read left before or after running the polling mechanism and
this would cause a race condition.
Now the pending read mechanism is properly waited for before returning
control back to the caller.
This should allow an easier way to query the Discord protocol gateway
latency, defined by the difference HEARTBEAT_ACK between and the last
sent HEARTBEAT.
This setting configures how long before a timeout event is emitted
internally and disconnects the websocket. Since some users were
experiencing issues with the gateway not responding, this should help
mitigate the issue for those with poor PCs.
In 3.5.0 and 3.5.1 asyncio.ensure_future requires a Future or a
coroutine otherwise a TypeError is raised. The issue is that the
websockets.connect call is an awaitable rather than a coroutine.
asyncio.ensure_future did not gain support for awaitables until 3.5.2.
This patch allows 3.5.0 and 3.5.1 to connect regardless of their python
version.
Rapptz
jack1142
Reece Dunham
NCPlayz
Dante Dam
SnowyLuma
Hornwitser
Gorialis
BeatButton
Tobotimus
verixx