Pierre Villard created NIFI-16082:
-------------------------------------
Summary: 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
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)
