Use cached_property to create Futures #1038
Conversation
and avoid trying to access possibly non-existent event loop in init methods, which allows to construct affected classes without a running event loop fix flaky test
| self._finish_lock = asyncio.Lock() | ||
|
|
||
| self._logger.debug("%s created", self) | ||
| asyncio.get_event_loop().create_task(self.timeout_game(setup_timeout)) | ||
|
|
||
| @cached_property | ||
| def _hosted_future(self) -> asyncio.Future: | ||
| return asyncio.get_event_loop().create_future() |
There was a problem hiding this comment.
Should we be using get_running_loop instead maybe? I'm not entirely sure what all the intricacies are but the asyncio docs for get_event_loop in python 3.10 say this:
Because this function has rather complex behavior (especially when custom event loop policies are in use), using the get_running_loop() function is preferred to get_event_loop() in coroutines and callbacks.
| @@ -139,8 +138,7 @@ async def test_game_matchmaking_start(lobby_server, database): | |||
| }) | |||
|
|
|||
| # Wait for db to be updated | |||
| await read_until_launched(host, game_id) | |||
| await read_until_launched(guest, game_id) | |||
| await game_service[game_id].wait_launched(None) | |||
There was a problem hiding this comment.
I feel like this change wouldn't make any difference. In fact, as far as I can tell from the code the read_until_launched method should actually always wait longer than the wait_launched method. So I'm not sure if this actually fixes the flakiness or if maybe you just got lucky when running the tests. But I could be missing something.
I also want to keep these integration tests using only the protocol messages as much as possible. So if we can use a protocol message to determine that the game launched instead of having to reach into the internal state of a service, that would be much better. That way it can reveal deficiencies in our protocol if there are some use cases that are not possible using only the existing messages.
Resolves #894
Also, fix one flaky test (
test_game_matchmaking_start) by fully waiting for the game to start.I took a look at other flaky tests, but I couldn't reproduce their flakiness: they had been continuing to pass.
The only flaky one which sometimes failed is
test_game_matchmaking_close_fa_and_requeue, and I believe this is happening due to@fast_forwardnot working as wished withloop.run_in_executorfutures.Removing
@fast_forwarddecorator fixes this test's flakiness, but increases runtime (from ~1 to about ~2.5 seconds), so I didn't touch that.