I think processors should really have well defined relationships for
the error scenarios that need to be handled. Having the exception
message is ok for a human who wants to see it, but in order to do
anything with it in the flow you will have to have a bunch of
parsing/interpreting of the message with a bunch of routing
processors, which seems more brittle than just having the appropriate
relationships.
On Thu, Oct 25, 2018 at 1:36 AM Peter Wicks (pwicks) <pwi...@micron.com> wrote:
>
> When a FlowFile is routed to failure, frequently there is no clear reason
> without looking into the actual error message.
> Some processors work around this by creating many different relationships,
> but even then frequently the generic Failure relationship also provides
> little guidance.
>
> I've seen a few cases recently where processors are including the exception
> message as an attribute on the FlowFile when routing to failure
> (ExecuteStreamCommand, new PR for ExecuteSQL). Should this be a standard
> pattern so that it's easier for users to route failures?
>
> --Peter
