An unusual exception may occur during runtime where the client attempts to set the result of a command already done, resulting in an asyncio.InvalidStateError.
Exception in callback _SelectorDatagramTransport._read_ready()
handle: <Handle _SelectorDatagramTransport._read_ready()>
Traceback (most recent call last):
File "/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/python3.10/asyncio/selector_events.py", line 1027, in _read_ready
self._protocol.datagram_received(data, addr)
File "/berconpy/protocol.py", line 447, in datagram_received
self._set_command(packet, message)
File "/berconpy/protocol.py", line 245, in _set_command
fut.set_result(message)
asyncio.exceptions.InvalidStateError: invalid state
This error occurred twice within a two hour span, and had been produced after the client was unable to connect to the server for 15 hours. It is unknown whether these were different futures, or if they were cancelled or had received duplicate responses. Majority of the log leading to the above error showed the client was unable to send commands or receive messages:
04:30:07: server has timed out (last received 46 seconds ago)
04:30:10: could not send command after 3 attempts
04:30:10: failed to receive players from server; player cache will not be available
04:31:24: server has timed out (last received 45 seconds ago)
04:31:27: could not send command after 3 attempts
04:31:27: failed to receive players from server; player cache will not be available
Afterwards the errors had discontinued, but the client was no longer connected to the server. Creating a new AsyncRCONClient was able to resolve the connection issue, but it may also have been resolved by calling AsyncRCONClient.connect()
again.
The steps to reproduce this are unclear, but it appears to happen after the network has temporarily lost connection.