[
https://issues.apache.org/jira/browse/NIFI-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-14823.
-----------------------------------
Resolution: Information Provided
> NiFi Processor becomes invalid due to a dynamic property sensitivity issue
> after NAR reupload
> ---------------------------------------------------------------------------------------------
>
> Key: NIFI-14823
> URL: https://issues.apache.org/jira/browse/NIFI-14823
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 1.28.1
> Environment: Official nifi-1.28.1 binaries. OS: Windows 11, GNU/Linux
> Reporter: Serhii Nesterov
> Priority: Minor
> Attachments: image-2025-08-06-03-55-23-773.png,
> image-2025-08-06-03-57-40-487.png
>
>
> I am working on a commercial project that uses Apache NiFi as an
> orchestration tool. There are plenty custom NARs with our custom processors
> and controller services that we build and upload to the extensions folder as
> part of a CD process during NiFi deployments. Sometimes we may make a mistake
> and accidentally upload a wrong version of NARs, and we observed that all
> processors that consist of at least a single non-sensitive property
> descriptor becomes invalid after uploading the correct version of the NAR. We
> believe this is a defect and NiFi should be able to restore dynamic
> properties as needed (in the same way as it restores static properties).
> Here are the steps to reproduce the issue:
> # Create a custom NiFi processor with one static and one non-sensitive
> dynamic property descriptors
> # Build a NAR and upload it to the extensions folder
> # Start NiFi
> # Put a new instance of the processor onto the canvas, fill in the static
> property with any value, and add a dynamic property with any name and value
> # Save the configuration
> # Stop NiFi
> # Delete the NAR from the extensions folder
> # Start NiFi. You will be able to see that NiFi cannot detect the processor
> which is expected since our NAR is absent
> # Stop NiFi
> # Get the NAR back to the extensions folder
> # Start NiFi. You will see that the processor is still highlighted as an
> invalid component. If you open its configuration, you will see that the
> static property value is restored, however the non-sensitive one isn't - it
> keeps being sensitive which is unexpected to us
> Here's what it looks like based on our custom PublishServiceBus that sends
> messages to Azure Service Bus:
> !image-2025-08-06-03-57-40-487.png!
> !image-2025-08-06-03-55-23-773.png!
> Current workaround that helps us restore invalid components:
> # Open the configuration of an invalid processor
> # Add a new dynamic property with any name and value
> # Save the configuration
> # Inspect the processor state - it got restored. The sensitivity of the
> broken property becomes false again as required and the value is now correct
> One disadvantage of the workaround is we need to apply it to each invalid
> component. So, if we have hundreds or thousands of such invalid components,
> then we would have to open a configuration of each of them and repeat the
> steps one after another which is a headache and is also problematic in
> production where the flow stays restricted for any modifications.
> Our expectation is to have NiFi restore the state of all non-sensitive
> properties once a necessary NAR gets uploaded and is compatible with the flow
> definition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
