[
https://issues.apache.org/jira/browse/NIFI-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serhii Nesterov updated NIFI-14823:
-----------------------------------
Description:
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.
was:
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 values is restored, however the non-sensitive one isn't - it keeps
being sensitive that we do not expect
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.
> 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)
