You can also check the NiFi logs for a searchable id or for what the previous processor ID produced to help search provenance. On Nov 19, 2015 21:22, "Bryan Bende" <bbe...@gmail.com> wrote:
> Charlie, > > The behavior you described usually means that the processor encountered an > unexpected error which was thrown back to the framework which rolls back > the processing of that flow file and leaves it in the queue, as opposed to > an error it expected where it would usually route to a failure relationship. > > Is the id that you see in the bulletin a uuid? > > There should still be some provenance events for this FlowFile from the > previous points in the flow. If it looks like the uuid of the FlowFile, > that should be searchable from provenance using the search button on the > right. Let us know if we can help more. > > -Bryan > > On Thu, Nov 19, 2015 at 9:10 PM, Charlie Frasure <charliefras...@gmail.com > > wrote: > >> I have a question on troubleshooting a flow. I've built a flow with no >> exception routing, just trying to process the expected values first. When >> a file exposes a problem with the logic in my flow, it queues up prior to >> the flow that is raising the bulletin. >> >> In the bulletin, I can see an id, but can't tell which file it is. Data >> provenance doesn't seem to help as it passed the flow on the last >> processor, but hasn't been logged (to my knowledge) on the next one. >> >> Is there a way to match the bulletin back to a file without creating a >> route for failed files? >> > >
