aiobotocore: Crash with aiohttp 3.1.x related to use of StreamReader
I’m getting a crash using aiobotocore 0.6.0 with aiohttp 3.1.0 (released yesterday 2018-03-21). It appears to be related to botocore’s response checking:
Traceback (most recent call last):
File "test.py", line 20, in <module>
loop.run_until_complete(main())
File "/usr/local/Cellar/python/3.6.4_4/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete
return future.result()
File "test.py", line 12, in main
response = await client.describe_table(TableName='orbit-prod-identities')
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/aiobotocore/client.py", line 94, in _make_api_call
operation_model, request_dict)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/aiobotocore/endpoint.py", line 290, in _send_request
exception)):
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/aiobotocore/endpoint.py", line 322, in _needs_retry
caught_exception=caught_exception, request_dict=request_dict)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/hooks.py", line 227, in emit
return self._emit(event_name, kwargs)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/hooks.py", line 210, in _emit
response = handler(**kwargs)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 183, in __call__
if self._checker(attempts, response, caught_exception):
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 251, in __call__
caught_exception)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 269, in _should_retry
return self._checker(attempt_number, response, caught_exception)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 317, in __call__
caught_exception)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 220, in __call__
return self._check_response(attempt_number, response)
File "/Users/adam/Desktop/aiobotocore-test/venv/lib/python3.6/site-packages/botocore/retryhandler.py", line 335, in _check_response
actual_crc32 = crc32(response[0].content) & 0xffffffff
TypeError: a bytes-like object is required, not 'StreamReader'
Here’s a minimal reproducer:
# -*- coding: utf-8 -*-
import asyncio
from pprint import pprint
import aiobotocore
async def main():
session = aiobotocore.get_session()
client = session.create_client('dynamodb')
response = await client.list_tables()
pprint(response)
await client.close()
if __name__ == '__main__':
loop = asyncio.get_event_loop()
loop.run_until_complete(main())
I’ve also tried client.describe_table
, which results in the same error. It seems like the semantics for StreamReader
have changed such that it can no longer be treated like data.
The crash does not occur with aiohttp 3.0.9.
Environment:
- Python 3.6.4
- aiobotocore 0.6.0
- aiohttp 3.1.0
- botocore 1.8.21
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 19 (9 by maintainers)
I edited changes.rst and broke formatting https://github.com/aio-libs/aiobotocore/pull/571 , anyway added command to test RST correctness.
https://pypi.org/project/aiobotocore/0.7.0/ released new version
@asvetlov @adamrothman figured it out, looks like
ClientResponse._content
was renamed toClientResponse._body
. Fix will be in: https://github.com/aio-libs/aiobotocore/pull/564Fixed by aiohttp 3.1.1 release
Sorry, guys. My personal fault. Support for sending
StreamReader
was dropped. I wanted to replace it with support for any async iterator by aio-libs/aiohttp/issues/2802But I did run too fast. Now I think the lost functionality is a critical bug, it will be fixed by pushing async iterator feature into next 3.1 bugfix release (coming soon).
Sorry again. @thehesiod could you postpone the locking aiohttp upper version?
As alternative I see the commitment on publishing a new aiobotocore version with the lock raised up to the latest aiohttp after every aiohttp release if tests are passed. It looks too complex burden.
On my side I wish to use the latest aiobotocore with the latest aiohttp (my company uses both libraries). I know about aiobotocore pain related to timeouts but I see a big progress on aio-libs/aiohttp/issues/2768 The first PR aio-libs/aiohttp/pull/2842 is not perfect from my perspective but personally I’ve got a vision how user interface would look like. I’m expecting to land new timeouts on aiohttp 3.2 1-2 months from now.
ya, we should have caught in https://github.com/aio-libs/aiobotocore/pull/536 that aiohttp needs to be upper-bound version locked. We need to add a comment so people don’t do this again.