[
https://issues.apache.org/jira/browse/NIFI-16082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard updated NIFI-16082:
----------------------------------
Status: Patch Available (was: In Progress)
> Connection update is incorrectly rejected when the current destination is
> running
> ---------------------------------------------------------------------------------
>
> Key: NIFI-16082
> URL: https://issues.apache.org/jira/browse/NIFI-16082
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> StandardConnectionDAO.verifyUpdate() guards changing a connection's
> destination while its current destination is running. Two problems:
> * Over-blocking. The guard fires whenever any connection field is submitted
> (name, back pressure, prioritizers, etc.), not only when the destination is
> actually changing. So renaming a connection or changing its back pressure is
> rejected with "Cannot change the destination of connection because the
> current destination is running" whenever the destination happens to be a
> running processor — even though the destination isn't changing. The check
> connection.getDestination() is also always non-null, so the intended "only
> when the destination is changing" condition is never actually evaluated.
> * Inconsistency with StandardConnection.setDestination. The low-level guard
> in setDestination was widened (NIFI-15906) to exempt Funnel, LocalPort, and
> RemoteGroupPort and to additionally block on unacknowledged (held) FlowFiles.
> verifyUpdate was not updated and still exempts only FUNNEL/INPUT_PORT (by
> ConnectableType). As a result the verify phase can reject a destination
> change (e.g. a running remote input port, or an output port) that
> setDestination would actually allow — a verify-vs-commit divergence.
> Fix: Introduce Connection.verifyCanUpdateDestination() implemented in
> StandardConnection by factoring out the existing setDestination guards
> (running-and-not-exempt, plus held/unacknowledged FlowFiles). setDestination
> and StandardConnectionDAO.verifyUpdate both call it, so the verify pre-check
> and the commit mutation apply identical rules and cannot drift again.
> verifyUpdate invokes it only for an actual destination change (id /
> remote-process-group comparison shared with updateConnection), so
> non-destination edits are no longer blocked. Existing setDestination behavior
> and check order are unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
