This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: asyncio.ensure_future() breaks implicit exception chaining
Type: behavior Stage: resolved
Components: asyncio Versions: Python 3.9, Python 3.8, Python 3.7, Python 3.6
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: asvetlov, chris.jerdonek, yselivanov
Priority: normal Keywords: patch

Created on 2020-05-01 09:57 by chris.jerdonek, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 19858 open chris.jerdonek, 2020-05-02 09:35
Messages (3)
msg367832 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2020-05-01 09:57
This issue is about how if a coroutine is wrapped in a Task with asyncio.ensure_future(), then portions of the exception chain can be lost.

Specifically, if you run the following code, then ValueError will be raised with exc.__context__ equal to the KeyError:

    import asyncio

    async def raise_error():
        raise ValueError

    async def main():
            raise KeyError
        except Exception as exc:
            future = raise_error()
            # Uncommenting the next line makes exc.__context__ None below.
            # future = asyncio.ensure_future(future)

                await future
            except Exception as exc:
                print(f'error: {exc!r}, context: {exc.__context__!r}')


However, if you uncomment the `asyncio.ensure_future()` line, then the ValueError will be raised with no __context__.

I originally raised this issue a couple years ago here:

There it was suggested that this was a special case of this issue:

However, after writing code to fix that, this issue still exists.
msg367925 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2020-05-02 11:34
My PR is ready for review:
msg368232 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2020-05-06 10:36
Closing this as a duplicate of

It turns out that, as Nathaniel first suggested, this is really just another special case of that issue (the "yield from" case as opposed to the "yield" case). It's just that the particular examples provided in that issue were for "yield" and not "yield from", so it wasn't immediately evident.
Date User Action Args
2022-04-11 14:59:30adminsetgithub: 84646
2020-05-06 10:36:11chris.jerdoneksetstatus: open -> closed
resolution: duplicate
messages: + msg368232

stage: patch review -> resolved
2020-05-02 11:34:54chris.jerdoneksetmessages: + msg367925
2020-05-02 09:35:32chris.jerdoneksetkeywords: + patch
stage: patch review
pull_requests: + pull_request19174
2020-05-01 09:57:11chris.jerdonekcreate