Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Awaiting on WebSocketResponse.send_* does not work #1645

Closed
mind1m opened this issue Feb 16, 2017 · 7 comments
Closed

Awaiting on WebSocketResponse.send_* does not work #1645

mind1m opened this issue Feb 16, 2017 · 7 comments
Labels
Milestone

Comments

@mind1m
Copy link
Contributor

mind1m commented Feb 16, 2017

Long story short

In documentation it says:

New in version 1.3.0.
To enable back-pressure from slow websocket clients treat methods ping(), pong(), send_str(), send_bytes(), send_json() as coroutines. By default write buffer size is set to 64k.

http://aiohttp.readthedocs.io/en/stable/web_reference.html?highlight=back%20pressure#websocketresponse

However, if I try to do it, I get:

Error handling request
Traceback (most recent call last):
  File ".../env/lib/python3.6/site-packages/aiohttp/web_server.py", line 62, in handle_request
    resp = yield from self._handler(request)
  File ".../env/lib/python3.6/site-packages/aiohttp/web.py", line 270, in _handle
    resp = yield from handler(request)
  File "ws_srv.py", line 8, in wshandler
    await ws.send_str('hello')
TypeError: object tuple can't be used in 'await' expression

It can be seen, that when writer's buffer is not full, WebSocketWriter._send_frame returns a tuple https://github.com/KeepSafe/aiohttp/blob/e49b59b0594ca4c21a3f788ffcbe0005c79daa65/aiohttp/_ws_impl.py#L457 . Maybe it should be async function or return a Future?

Expected behaviour

Awaiting on WebSocketResponse.send_* should work.

Actual behaviour

Awaiting on WebSocketResponse.send_* when buffer is not full results in TypeError: object tuple can't be used in 'await' expression.

Steps to reproduce

ws_server.py

import asyncio
from aiohttp.web import Application, WebSocketResponse, run_app


async def wshandler(request):
    ws = WebSocketResponse()
    await ws.prepare(request)
    await ws.send_str('hello')
    await ws.close()
    print('Processed client')
    return ws

async def init(loop):
    app = Application(loop=loop)
    app.router.add_get('/', wshandler)
    return app

loop = asyncio.get_event_loop()
app = loop.run_until_complete(init(loop))
run_app(app)

ws_client.py

import asyncio
import aiohttp


async def f():
    session = aiohttp.ClientSession()
    async with session.ws_connect('http://localhost:8080') as ws:
        answer = await ws.receive_str()
        assert answer == 'hello'
        print('Got correct answer, exiting..')
    await session.close()

asyncio.get_event_loop().run_until_complete(f())

Your environment

aiohttp 1.3.1, Python 3.6, OS 10.12.2

@mind1m
Copy link
Contributor Author

mind1m commented Feb 16, 2017

I can prepare PR, if someone advises me on how to fix the issue.

@kxepal
Copy link
Member

kxepal commented Feb 16, 2017

But all websocket write methods are not awaitable since the start. Why to make them awaitable?

@kxepal
Copy link
Member

kxepal commented Feb 16, 2017

Hm...I guess, documentation need to clarify the moment with "coroutines". /cc @fafhrd91

@fafhrd91
Copy link
Member

Technically they are not coroutines but they return coroutine object

@fafhrd91
Copy link
Member

@mind1master we need to add empty coroutine and return it instead of ()

@fafhrd91 fafhrd91 added this to the 1.3.2 milestone Feb 16, 2017
@fafhrd91
Copy link
Member

fixed in 1.3 branch, i will release 1.3.2 later today

@lock
Copy link

lock bot commented Oct 29, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants