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)

Most upvoted comments

I edited changes.rst and broke formatting https://github.com/aio-libs/aiobotocore/pull/571 , anyway added command to test RST correctness.

@asvetlov @adamrothman figured it out, looks like ClientResponse._content was renamed to ClientResponse._body. Fix will be in: https://github.com/aio-libs/aiobotocore/pull/564

Fixed 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/2802

But 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.