[ 
https://issues.apache.org/jira/browse/NIFI-16267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18110309#comment-18110309
 ] 

Mike Thomsen edited comment on NIFI-16267 at 9/1/26 2:05 PM:
-------------------------------------------------------------

[~exceptionfactory] I've been working on an AI-assisted project to try to build 
a tool that can wrap stateless NiFi for the purpose of creating an integration 
test runner harness for stateless NiFi. In doing that, I discovered that 
stateless NiFi doesn't appear to have any hooks where a tool can 
programmatically build a stateless NiFi configuration and hook into its error 
handling and counter tracking so that it can do things like track which 
processor failed and why nor count counters (or even monitor failure ports).

This is where that idea started, and locally it's evolving beyond the scope of 
this ticket. So if I were to propose a NIP it would be now more as an 
observability update to help external tooling have a clear public API to hook 
into stateless NiFi so that stateless NiFi would not be dependent on its own 
flow to know if something succeeded or failed (and why).

(The goal of the harness was to make a flow testable in something like GitHub 
Actions or Jenkins, including up to providing eventually secret injection; my 
local version I'm testing with can already take a yaml-defined parameter 
context and apply it to the flow being parsed from JSON in stateless NiFi)


was (Author: mike.thomsen):
[~exceptionfactory] I've been working on an AI-assisted project to try to build 
a tool that can wrap stateless NiFi for the purpose of creating an integration 
test runner harness for stateless NiFi. In doing that, I discovered that 
stateless NiFi doesn't appear to have any hooks where a tool can 
programmatically build a stateless NiFi configuration and hook into its error 
handling and counter tracking so that it can do things like track which 
processor failed and why nor count counters (or even monitor failure ports).

This is where that idea started, and locally it's evolving beyond the scope of 
this ticket. So if I were to propose a NIP it would be now more as an 
observability update to help external tooling have a clear public API to hook 
into stateless NiFi so that stateless NiFi would not be dependent on its own 
flow to know if something succeeded or failed (and why). 

> Add a basic component failure listener to stateless NiFi to help external 
> tooling track failures
> ------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-16267
>                 URL: https://issues.apache.org/jira/browse/NIFI-16267
>             Project: Apache NiFi
>          Issue Type: Improvement
>            Reporter: Mike Thomsen
>            Assignee: Mike Thomsen
>            Priority: Major
>
> While doing some experimentation with stateless NiFi as a potential way to do 
> integration tests on NiFi flows in Jenkins, I found that there appears to be 
> no way to enable external tooling to hook into stateless NiFi to capture 
> component failures. I am proposing a modest listener style plugin that can be 
> programmatically added by tools that embed or launch stateless NiFi.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to