Thanks David! I think that completely answers my question. On Wed, Oct 6, 2021 at 3:25 PM David Li <[email protected]> wrote:
> 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! > > > >
