[jira] [Commented] (NIFI-16442) Apply connector property migration when a configuration provider document is loaded

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on NIFI-16442:
--------------------------------------------------------

Commit 702e6d29f94e57c4d0da2c614265856573e6820c in nifi's branch refs/heads/main from Matt Gilman
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=702e6d29f94 ]

NIFI-16442: Persist migrated Connector properties (#11789)

* NIFI-16442: Persist migrated Connector properties

Apply Connector property migrations when loading configuration provider
documents and persist the migrated form during flow synchronization.
Preserve runtime-only defaults, retry failed saves and inheritance, and
atomically replace complete Connector configurations.

* NIFI-16442: Addressing review feedback.

* NIFI-16442: Addressing review feedback.

> Apply connector property migration when a configuration provider document is loaded
> -----------------------------------------------------------------------------------
>
>                 Key: NIFI-16442
>                 URL: https://issues.apache.org/jira/browse/NIFI-16442
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>            Reporter: Matt Gilman
>            Assignee: Matt Gilman
>            Priority: Major
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> When a ConnectorConfigurationProvider is configured, a connector property migration does not survive the provider document.
> Connector.migrateProperties runs while inheriting or reloading a connector and updates the in-memory working configuration. The provider document is left unchanged. The next provider load installs that document through replaceWorkingConfiguration without running migrateProperties. Configuration-step verification syncs from the provider first, so the obsolete property name is present when AbstractConnector validates the step:
> Property '<old property name>' is not defined by the Connector for Configuration Step '<step name>'
> On an individual configuration step, that failure is easy to miss because the result subject is the old property name and does not match a current descriptor. Verifying the full configuration reports it.
> Reads and writes need to stay separate. ConnectorConfigurationProvider loads on read and saves on write. ConnectorSyncMode.SYNC_WITH_PROVIDER refreshes memory from the external store. A read must not save.
> Expected behavior:
> - When a provider document is loaded, including configuration-step verification and getConnector(SYNC_WITH_PROVIDER), migrate it in memory before installing it. Verification then sees the current property names. Do not call ConnectorConfigurationProvider.save from that path.
> - During flow synchronization, when getSyncDirective supplies a working configuration, persist the migrated stored keys through the existing save. This follows notifyMigrationComplete: the framework originated the change, so the external document is updated. Do not persist required defaults that the framework applied because they were missing. Do not persist anything when the connector declares no configuration steps.
> - Compare persisted forms when deciding whether the working configuration changed. A framework-applied required default must not make every later flow synchronization call inheritConfiguration.
> - If the new property name is already present, renameProperty keeps that value and removes the old key.
> - If save throws, catch it for that connector, inherit the migrated configuration in memory, and leave the provider document unchanged. VersionedFlowSynchronizer.inheritConnectors does not catch exceptions from syncConnector, so a thrown save must not abort the remaining connectors. The next flow synchronization tries the save again. Verification does not.
> Tests:
> - A provider document with a renamed property is installed under the new name, and the load does not call save.
> - Flow synchronization calls save with the renamed document and without a framework-applied required default. A second synchronization of the same document does not call save, and it does not call inheritConfiguration only because memory contains that default.
> - When both the old and new property names are present, the new name keeps its value.
> - When save throws, syncConnector returns and a later synchronization calls save again.



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