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

Capture exception traceback from remote #77

Closed
ooq opened this Issue Feb 28, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@ooq
Copy link
Collaborator

ooq commented Feb 28, 2017

We capture the internal exception from wrenhandler, but did not include traceback information in the response.

@ericmjonas

This comment has been minimized.

Copy link
Collaborator

ericmjonas commented Feb 28, 2017

@ooq For some reason I thought we did this, or am I misunderstanding? https://github.com/pywren/pywren/blob/master/pywren/jobrunner.py#L50

Do you have a snippet of code that shows the problem and the desired behavior?

@ooq

This comment has been minimized.

Copy link
Collaborator

ooq commented Mar 1, 2017

@ericmjonas Ah, right. I found a remote exception without traceback. I though it's from user program, but it's actually from wrenhandler.py.
We should also propagate traceback for exceptions in wrenhandler.py. I'll change the description of this issue.

@ericmjonas

This comment has been minimized.

Copy link
Collaborator

ericmjonas commented Mar 1, 2017

The challenge with the traceback (and even the exception) -- you'll note that unlike our attempts to pickle the exception inside jobrunner.py, we can never be guaranteed the python version on the client is correct, so reraise isn't going to be very helpful here.

Would pretty-printing a traceback into a string and returning that be enough, since we can't get a "real" traceback?

@ooq

This comment has been minimized.

Copy link
Collaborator

ooq commented Mar 1, 2017

Yeah, I'm thinking just to add another field in response_status with something like traceback.format_exc() when we catch the exception in wrenhandler. I don't think we need to propagate the actual exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment