Open janosh opened 1 month ago
pinging @utf @Andrew-S-Rosen @JaGeo in case you have thoughts?
Second this.
Also,
The raise_immediately
flag kind of handles this:
https://github.com/materialsproject/jobflow/blob/e61b50fc864dd20221adb3c331b5887a3c184e42/src/jobflow/managers/local.py#L24
I feel real-world exceptions are so deep down the call stack that reading things becomes problematic. I have been running this flag and
ipython --pdb test.py
to debug workflows and it's been pretty effective.
thanks for the tip! i'll give the raise_immediately=True
+ ipython --pdb
combo a try
when debugging a failing workflow with
run_locally
, it can be very helpful to have access to the exception object. currently, you always get the same generic error:https://github.com/materialsproject/jobflow/blob/e61b50fc864dd20221adb3c331b5887a3c184e42/src/jobflow/managers/local.py#L181
to see what went wrong, you have to run with
and then hunt for the error message in the logs which can be verbose
how about we raise the actual error message instead of this generic
RuntimeError
? a (possibly bad style) sketch of how to implement this:for the above to work,
_run_job
would have to be modified to return the caught exception: