Yes, this looks right. Two small things, sorry this was my mistake: for 2) you'll need corresponding code on the client to unpack the exception. So 1) is probably the simplest.
for 3) you're right, we pass you only the status, not the full traceback as you wanted. (A reraise won't get you the traceback since we fundamentally don't give you that, only the error object.) So the decorator is your best bet. -David On Wed, Oct 6, 2021, at 17:51, Michael Ark wrote: > David, > > Thank you, that’s very helpful. > > So to be clear, my options are: > > 1) Stick with out of the box behavior but wrap all my functions on my server > in decorators that catch exceptions and reraise them with a trace back > appended to the message. > 2) Stick with out of the box behavior but wrap all my functions on my server > in decorators that catch exceptions and reraise them AS FLIGHT ERRORS with a > trace back appended to the ‘extra_info’ > 3) Some kind of middleware logging to log somewhere else instead of sending a > trace back to the client, but I would not really have access to the trace > back since the original error didn’t include it, unless I included it using a > reraise above. > > Is this an accurate assessment? > > Thank you for your help! > > On Wed, Oct 6, 2021 at 2:46 PM David Li <[email protected]> wrote: >> __ >> Hey Michael, >> >> Unfortunately that's the best you can do at the moment (a decorator will at >> least help you get rid of the boilerplate). >> >> Note that when raising the Flight-specific exceptions from pyarrow.flight, >> you can pass a second 'extra_info' argument which is a binary blob that'll >> get sent to the client. You can then unpack this on the client, so you could >> stuff the traceback there. (Note that this blob isn't included in the >> message by default. It's accessible via FlightError.extra_info.) >> >> Middleware can be used to intercept requests and log exceptions server-side, >> but they don't get to modify the error response. In principle this could be >> implemented, though - would that help? >> >> Best, >> David >> >> On Wed, Oct 6, 2021, at 17:34, Michael Ark wrote: >>> I noticed when I get server-side errors on Apache Arrow Flight, my Flight >>> client will get the following `FlightServerError`, with the original >>> message and Python exception that was raised. The traceback, however is not >>> for the server-side code. Is there a way to include the original Python >>> code traceback for all FlightServerErrors? One way I can think of doing >>> this is try-except all errors in each server function and reraise the >>> errors with the traceback concatenated with the original message, but this >>> seems hacky. >>> >>> > pyarrow._flight.FlightServerError: 'snetio' object has no attribute >>> > '_sdict'. Detail: Python exception: AttributeError >>> > pyarrow/_flight.pyx:60: FlightServerError >>> >>> Thanks and appreciate your input! >>
