Interrupt lu transformation generators whenever an exception occurs #4226
Conversation
This fixes some errors that have been appearing in our CI from time to time. All transformations are implemented as generators, but they haven't been explicitly aborted when an exception has been raised. Instead, they only got closed when they got garbage collected, which could happen at an unspecified later time, potentially leading to a corruption of global state, which could have been modified after the exception was handled. Note that this implementation doesn't propagate the original exception into the argument transformations, and doesn't allow them to handle the error either. Such an extension would be possible, but throwing an exception into a generator mutates the exception object, clobbering the nice traceback that we would usually carry. One can work around those issues, but it feels really hacky and we don't need it right now anyway, so I figured we'll be better off with the simple thing for the time being.
|
Fixes #3271 (I think?) |
froystig
approved these changes
Sep 9, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.


This fixes some errors that have been appearing in our CI from time to
time. All transformations are implemented as generators, but they
haven't been explicitly aborted when an exception has been raised.
Instead, they only got closed when they got garbage collected, which
could happen at an unspecified later time, potentially leading to a
corruption of global state, which could have been modified after the
exception was handled.
Note that this implementation doesn't propagate the original exception
into the argument transformations, and doesn't allow them to handle the
error either. Such an extension would be possible, but throwing an
exception into a generator mutates the exception object, clobbering
the nice traceback that we would usually carry. One can work around
those issues, but it feels really hacky and we don't need it right now
anyway, so I figured we'll be better off with the simple thing for the
time being.
The text was updated successfully, but these errors were encountered: