Greg, You wouldn’t want to retry the “original” relationship. The processor has 3 relationships: original, output stream, and nonzero status. It should always send the incoming FlowFile to original. So if you retry that relationship you’ll always retry the flowfile, regardless of whether it was successful or not.
Instead, you should retry the “nonzero status” relationship. If a FlowFIle is routed to this relationship, it will instead be re-queued and processed again. Nothing will go to original in this case, because the processing is atomic. But if a FlowFile is routed to the “output stream” relationship (because it’s not retried) the FlowFile will continue on normally. And the original FlowFile will go to ‘original’. Additionally, if all retries are completed and it still is routed to “nonzero status” then at that point, the FlowFile will go to “nonzero status” and the original will be transferred to whatever connection (if any) you have for the “original” relationship. Does that help? Thanks -Mark > On Jul 20, 2022, at 9:12 AM, Gregory M. Foreman > <gfore...@spinnerconsulting.com> wrote: > > Hello: > > The ExecuteStreamCommand processor has 3 relationships. To trap processing > failures, I capture flowfiles from the original relationship, inspect the cmd > exit status, and reroute to a RetryFlowFile processor if the exit status is > not 0. I wanted to see if this could be simplified with the new retry > feature in 1.16. When I enable retry on the original relationship and > execute a failing cmd, the flowfiles remain penalized in the previous success > queue, but never exit to the original relationship. Is this scenario > supposed to work as I have it setup? > > Thanks, > Greg
