-
Notifications
You must be signed in to change notification settings - Fork 158
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
Unhandled exceptions occurring inside function passed to executor.map
are swallowed
#776
Comments
Thanks a lot for bringing this issue to our attention, and for writing a test case. I agree that the generator result should be consumed in principle, but we catch and log all exceptions (as you've already pointed out) here. I have to dig deeper, but my bet would be that there's a different underlying cause :-/. |
FWIW, I've ran into this in CLI tests when dummy conversion is used. The I do not have a test case when using e.g. the container isolation provider (which IIUC uses the To simulate a swallowed exception when using the container provider, we would have to raise it explicitly. E.g. try adding
|
Got it. So we practically need a |
Indeed. IIUC this wrapping handler should also mark the document as failed upon exception (if it was not done already) to correctly report it at the end. |
I'm interested in contributing to this |
Cool! Hopefully this issue provides enough context. In a nutshell, we want to:
Happy to answer any question you may have 🙂 |
Setting up the environment might take a while because I'm busy right now |
Currently, if an unhandled exception occurs inside
convert_doc
when runningdangerzone-cli
, the exception is swallowed (traceback is not logged, the exit code is not changed).This manifests in tests with dummy conversion - e.g. if
shutil.copy
raises an exception (e.g.src
anddst
being the same path), theCLIResult
is still reported as a success due to the swallowed exception. Here is a demo test case.IIUC during actual (not dummy) execution it would hide potential exceptions occurring here or here.
I believe this is because the generator returned by
executor.map
is not consumed - fromThreadPoolExecutor
docs:Here is a simplified form showing the issue:
The text was updated successfully, but these errors were encountered: