What's wrong with this async aiohttp code?

Question

For the following code using aiohttp:

async def send(self, msg, url):
    async with aiohttp.ClientSession() as session:
        async with session.post(url, data=msg) as response:
            self._msg = response.read()

async def recv(self):
    return await self._msg

It works... Most of the time, but occasionally (frequently, actually) results in various exceptions - usually truncated responses, or a connection already being closed exception.

By contrast, the following works perfectly:

async def send(self, msg, url):
    async with aiohttp.ClientSession() as session:
        async with session.post(url, data=msg) as response:
            self._msg = await response.read()

async def recv(self):
    return self._msg

I would like to know why, as the second version is technically incorrect for my purposes and I need to fix it. (It is incorrect because the recv function might be called before the response has been read)

"It is incorrect because the recv function might be called before the response has been read" - if it's called before the response has been read, then what's it going to await in the first version? self._msg hasn't been set yet. — user2357112
– user2357112, Commented Sep 14, 2017 at 0:03
Exactly, the code I have just happens to never call recv until well after send has completed. But ah, that's a really good point, it turns out that both versions are fundamentally wrong. Can you suggest a fix, while still keeping the 'send' and 'recv' conceptually separate? — Arafangion
– Arafangion, Commented Sep 14, 2017 at 0:05
(To clarify: Whilst I'd appreciate the fix, the real answer I want out of this is to understand the difference between those two code samples) — Arafangion
– Arafangion, Commented Sep 14, 2017 at 0:16

Alex Undefined · Accepted Answer · 2017-09-14 02:43:55Z

2

with is a context manager, it runs some code before and after any statements within it's block, bookkeeping usually. Meaning, your first recv function most likely awaits on a future that references an already closed connection, or something along these lines.

Let's say you have some code that looks like this:

with open(...) as file:
    file.read()

This is what it does, roughly:

file = open(...)
file.read()
file.close()

And this is the equivalent of what you're doing in your first example:

file = open()
file.close()
...
file.read()

edited Sep 14, 2017 at 2:43

answered Sep 14, 2017 at 0:56

Alex Undefined

6301 gold badge5 silver badges8 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Arafangion Over a year ago

And that invalidates the future?

Alex Undefined Over a year ago

I don't know what do you mean by "invalidates the future" exactly, but, basically, this whole thing is not an asyncio issue. It's an issue of reading from a closed socket, or something else that happens deep in the response.read().

Alex Undefined Over a year ago

Updated the answer.

Collectives™ on Stack Overflow

What's wrong with this async aiohttp code?

1 Answer 1

3 Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Your Answer

Sign up or log in

Post as a guest

Related