Looks like an issue in Python 3 as well. Insofar as this get fixed (I will try to, or would be happy to accept PR), it's only going to be fixed in newer releases, though, so it won't work on Python 2.

Yea, that's more or less what I expected. Depending on what the fix looks like, I might try to put in some time backporting it, though whether that's something that makes it into a new Eliot 1.7.x release or if I have to put it elsewhere, I dunno? Any thoughts on that?

(Maybe too early to say, I have no idea what the fix is going to look like.)

I'm... not really sure what's going on apriori. We catch the exception, yes, but then we throw it again through the generator with the same traceback. So oughtn't do the right thing?

I can do a 1.7.1 release, given a backported PR.

I'm really hoping, BTW, to eventually be able to rip out all the Twisted-specific code and rely on twisted/twisted#1192

Haven't tested that, though, so not sure how well it works compared to current solution.

I think this is at least partially an issue with twisted. If I remove this line, then the correct traceback is printed. Thus, it looks like it happens when an error happens synchronously, as the inner function returns an already failed deferred, which thus has its failure cleaned.

It looks like the reason it works without eliot's wrapper is that Failure digs around in the traceback to find the Failure object an exception corresponds to, and merges the tracebacks of the two.

Haven't tested that, though, so not sure how well it works compared to current solution

Changing

value_out = go()

makes the twisted tests still pass. (Though as mentioned in #472, it would be good to keep that code around for other reasons.