Sven Van Kerrebroeck created NIFI-15840:
-------------------------------------------

             Summary: ExecuteGroovyScript fails with "Failure Strategy = 
transfer to failure" in NiFi 2.9.0
                 Key: NIFI-15840
                 URL: https://issues.apache.org/jira/browse/NIFI-15840
             Project: Apache NiFi
          Issue Type: Bug
          Components: Core Framework
    Affects Versions: 2.9.0
            Reporter: Sven Van Kerrebroeck
         Attachments: GroovyScript_reproduce_flow.json, 
image-2026-04-15-16-09-21-039.png

After upgrading from Apache NiFi 2.8.0 to 2.9.0, we observed a regression in 
the *ExecuteGroovyScript* processor when using {{Failure Strategy = transfer to 
failure}}

In this configuration, the processor fails with FlowFileHandlingException 
errors instead of properly routing FlowFiles to the failure relationship.

The issue occurs even with trivial scripts that simply transfer a FlowFile to 
success.

When switching the same processor to {{{}Failure Strategy = rollback{}}}, the 
processor behaves normally and processes FlowFiles without errors.

In v2.8.0 this worked correctly. 
----
When "{{{}Failure Strategy = transfer to failure"{}}} is configured, the 
processor throws errors such as:

 
{code:java}
org.apache.nifi.processor.exception.FlowFileHandlingException: 
StandardFlowFileRecord[uuid=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,claim=,offset=0,name=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,size=0]
 transfer relationship not specified. This FlowFile was not created in this 
session and was not transferred to any Relationship via 
ProcessSession.transfer(): 
org.apache.nifi.processor.exception.FlowFileHandlingException: 
StandardFlowFileRecord[uuid=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,claim=,offset=0,name=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,size=0]
 transfer relationship not specified. This FlowFile was not created in this 
session and was not transferred to any Relationship via 
ProcessSession.transfer()

Processing halted: yielding [1 sec]: 
org.apache.nifi.processor.exception.FlowFileHandlingException: 
StandardFlowFileRecord[uuid=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,claim=,offset=0,name=4128e0b1-0f4c-4da3-82f4-8edf81334c3c,size=0]
 is not known in this session (StandardProcessSession[id=48607982])


{code}
 

This happens even when:
 * the script explicitly transfers the FlowFile to REL_SUCCESS
 * no exception is thrown by the script itself

*Steps to Reproduce*
 * In NiFi 2.9.0, create a new ExecuteGroovyScript processor
 * Set: Failure Strategy = transfer to failure
 * Use the following minimal script:

{code:java}
def ff = session.get()
if (!ff) return
session.transfer(ff, REL_SUCCESS) {code}

 * connect an incoming flowfile
 * add success and failure output queues
 * start the processors

_(I added the export of this small example/test flow in attachment)_

!image-2026-04-15-16-09-21-039.png!

 
----
*Workaround* (for those who need it): 
 * Depending on situation you can use ExecuteScript processor instead of 
ExecuteGroovyScript (but not always possible if you use CTL.* property's for 
example) 
 * other option: add try-catch error handling around the whole script (right 
after the session.get) and keep "Failure Strategy = rollback". Then make sure 
in the catch that you transfer to failure output when needed (and add usefull 
messages/attributes)
For example: 

 
{code:java}
def flowFile = session.get()
if (!flowFile) return
try {
    // =========================
    // YOUR LOGIC HERE
    // =========================
    // Always end with exactly ONE action:
    session.transfer(flowFile, REL_SUCCESS)
} catch (Exception e) {
    log.error("Processor failed for FlowFile ${flowFile?.uuid}: ${e.message}", 
e)
    try {
        flowFile = session.putAttribute(flowFile, "error.message", e.message ?: 
e.toString())
        flowFile = session.putAttribute(flowFile, "error.class", 
e.getClass().getName())
    } catch (ignored) {
        log.error("Failed to set error attributes", ignored)
    }
    session.transfer(flowFile, REL_FAILURE)
}
{code}



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

Reply via email to