You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2020-03-14.07:17:26.326>created_at=<Date2020-03-09.16:29:08.544>labels= ['type-bug', '3.8', '3.9', 'expert-asyncio']
title='await_args_list in AsyncMock always refers to the last awaited call object'updated_at=<Date2020-03-14.07:17:26.320>user='https://bugs.python.org/MadsSejersen'
It can actually be boiled down to an even more minimal example. It looks like the problem is that the function call is stored for later when called, then overwritten by other subsequent calls. Then, once awaited, the latest registered call is added to the await_args_list instead of the call that actually happened.
Thanks for the report. At  self.call_args is used. This value is always the last call. So when the object is awaited it will be always the last call object and gets appended. The id of the call objects remain the same. The fix would be to construct the call object with args and kwargs in asynchronous definition of _execute_mock_call like . This would need tests too. It seems there is only test for one await call and assertion over await_args_list. Having different args and kwargs with multiple await to assert await_args_list would help here. In synchronous case the call object is eagerly appended so it won't be an issue.
diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 9e692981a2..20daf724c1 100644
--- a/Lib/unittest/mock.py+++ b/Lib/unittest/mock.py@@ -2171,7 +2171,7 @@ class AsyncMockMixin(Base):
# This is nearly just like super(), except for special handling
# of coroutines
- _call = self.call_args+ _call = _Call((args, kwargs), two=True)
self.await_count += 1
self.await_args = _call