[jira] [Comment Edited] (NIFI-10303) GetElasticsearch processor invokes elasticsearch GET api without an identifier when flow file is null

["Chris Sampson (Jira)" <ji...@apache.org>]

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

Chris Sampson edited comment on NIFI-10303 at 10/24/22 7:31 PM:
----------------------------------------------------------------

I don't think the {{input == null}} shotcut is appropriate here as it's legitimate that no input FlowFile may be preset for {{GetElasticsearch}}.

However, you're right that it shouldn't try to execute a {{GET}} to Elasticsearch if no {{_id}} (and/or {{index}} or {{type}} where used) is present once any Expression Language has been evaluated for the processor's run {{onTrigger}}. Maybe the most appropriate thing to do would be to:
* route the input FlowFile to {{failure}} (if there was a non-null {{input}}), so that it can be handled appropriately by the Flow and the Flow maintainers can identify why no {{_id}} was present for the call
* log an error and {{yield}} the processor if there was no {{input}} FlowFile at all, e.g. the processor is scheduled to run automatically on a Cron Schedule (or whatever) with an {{_id}} that might be a Parameter or Variable Registry entry (or just a blank string) - this should generate Bulletins for the Flow maintainers to spot and fix as it's a Flow configuration issue at that point


was (Author: chris s):
I don't think the {{input == null}} shotcut is appropriate here as it's legitimate that no input FlowFile may be preset for {{GetElasticsearch}}.

However, you're right that it shouldn't try to execute a {{GET}} to Elasticsearch if no {{_id}} (and/or {{index}} or {{type}} where used) is present once any Expression Language has been evaluated for the processor's run {{onTrigger}}. Maybe the most appropriate thing to do would be to:
* route the input FlowFile to {{failure}} (if there was a non-null {{input}}), so that it can be handled appropriately by the Flow and the Flow maintainers can identify why no {{_id}} was present for the call
* log and error and {{yield}} the processor if there was no {{input}} FlowFile at all, e.g. the processor is scheduled to run automatically on a Cron Schedule (or whatever) with an {{_id}} that might be a Parameter or Variable Registry entry (or just a blank string) - this should generate Bulletins for the Flow maintainers to spot and fix as it's a Flow configuration issue at that point

> GetElasticsearch processor invokes elasticsearch GET api without an identifier when flow file is null
> -----------------------------------------------------------------------------------------------------
>
>                 Key: NIFI-10303
>                 URL: https://issues.apache.org/jira/browse/NIFI-10303
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 1.16.3
>            Reporter: Vijaya Gorla
>            Priority: Major
>              Labels: elasticsearch
>
> When GetElasticsearch processor has an incoming connection, and the document id is an expression, this results in expression evaluating to null when the processor runs without a flow file. This in turn results in elasticsearch GET api being invoked without an ID and elastic throwing an error.
> Also noticed that other processors handle this scenario by short-circuiting at the beginning of onTrigger method
> {code:java}
>         FlowFile input = null;
>         if (context.hasIncomingConnection()) {
>             input = session.get();
>             // If we have no FlowFile, and all incoming connections are self-loops then we can continue on.
>             // However, if we have no FlowFile and we have connections coming from other Processors, then
>             // we know that we should run only if we have a FlowFile.
>             if (input == null && context.hasNonLoopConnection()) {
>                 return;
>             }
>         }
> {code}
> However GetElasticsearch  does not.



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