__globals__ and AST parsing exception handling#123
Conversation
|
@ngoldbaum Pushed a commit that makes it so it quietly handles |
|
Maybe @lysnikolaou can suggest a reasonable way to add a test and confirm that this fixes sqlalchemy. |
|
Thanks for the PR @bwhitt7! While the PR looks good, I think we should go with what @ngoldbaum proposed in #121 (comment) and wrap the whole thing (probably these two lines) in a try/except. |
|
@lysnikolaou Gotchu! Wrapped those lines with a try/except. I noticed that other try/excepts in the |
| except Exception as e: | ||
| return ( | ||
| True, | ||
| f"caught {type(e).__name__} exception while parsing AST, please report bug to pytest-run-parallel: {e}", |
There was a problem hiding this comment.
| f"caught {type(e).__name__} exception while parsing AST, please report bug to pytest-run-parallel: {e}", | |
| f"caught {type(e).__name__} exception with content {repr(e)} while parsing the AST of test function {repr(fn)}, please report a bug to pytest-run-parallel at https://github.com/Quansight-Labs/pytest-run-parallel/issues/new including this error and accompanying traceback.", |
This probably makes the line really long, you might need to reformat it too.
It might also be useful if this message included the accompanying traceback too. You can get the traceback from an exception like this:
>>> import traceback
>>> try:
... raise RuntimeError
... except Exception as e:
... tb = traceback.format_exc()
...
>>> tb
'Traceback (most recent call last):\n File "<python-input-0>", line 2, in <module>\n raise RuntimeError\nRuntimeError\n'
>>> print(tb)
Traceback (most recent call last):
File "<python-input-0>", line 2, in <module>
raise RuntimeError
RuntimeError
Also I think this is getting complicated enough it probably deserves a test. You could maybe directly import identify_thread_unsafe_nodes from the pytest-run-parallel implementation and pass it a test function that you know will raise an exception during AST parsing. Maybe it could override __getattribute__ so if someone tries to access __globals__ on it, it raises a RuntimeError? Hopefully that idea works but if it doesn't maybe we can come up with something else...
I don't think there's any need to try to use the pytest testing utilities for this and make sure the pytest output is correct - just write a "normal" pytest test specifically for this error.
Refactor exception handling and add a test
|
This last push adds more specific exception handling to |
lysnikolaou
left a comment
There was a problem hiding this comment.
LGTM! Good work!
@ngoldbaum Would you mind giving this another look?
ngoldbaum
left a comment
There was a problem hiding this comment.
Just one small suggestion to simplify the try/except. Untested but I think it should work.
|
Thanks for taking this on @bwhitt7! |
This PR hopes to fix #121, addressing errors when running tests that have
__globals__that are not iterable (such as some tests in SQLAlchemy, as shown in the issue).This PR wraps the
__globals__in a try-except that will mark the test at thread-unsafe and print a message about the test's__globals__not being iterable (I'm open to suggestions for a more user-friendly message haha). This stops AST parsing and runs the test as normal without parallel threads. I also put a try-except around the entire AST parsing loop, so that if we run into any other issues like this in the future, pytest-run-parallel can handle the error and recommend that the user report the bug.An example when running the tests in
sqlalchemy/test/base/test_typing_utils.py(link)