Mike, Thanks for proposing this addition to NiFi Stateless behavior.
The concept of observing lower-level details in the Stateless flow makes sense at one level, but also raises a few more motivation questions. The CI/CD use case is a good one in general, and I can see why it could be useful to get more details on whether the flow might have failed. Although it would be a bit more indirect, did you consider some alternative type of Bulletin Repository or Provenance Repository that could surface this information? The Bulletins provide the component-level message and Provenance keeps track of processing outcomes, so building something in that direction seems to align more with the general approach of NiFi itself. The new listener surface seems focused enough to avoid significant changes, but I raise the question of alternatives to evaluate whether this approach aligns with Stateless in general, or whether it starts observability going in a different direction. I would also look for input from Mark Payne given his extensive work with Stateless and NiFi itself. Regards, David Handermann On Sat, Sep 12, 2026 at 5:31 AM Mike Thomsen <[email protected]> wrote: > > I have created a NIP to add some additional capabilities to Stateless NiFi > that would make it much easier for calling applications to track failure > signals in NiFi components. > > https://issues.apache.org/jira/browse/NIP-46 > > The need for this NIP came about while I was working on a tool to run NiFi > flows inside of a test harness, but I think it could also be useful in > general for other applications of Stateless NiFi such as launching it from > a stateful flow. > > Assuming no objections, I plan to start a lazy-consensus vote soon. > > Thanks, > > Mike
