[
https://issues.apache.org/jira/browse/NIFI-14823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012340#comment-18012340
]
Pierre Villard commented on NIFI-14823:
---------------------------------------
This is expected behavior. NiFi is always on the safe side and will always
assume that a property is sensitive when it does not have the information about
it.
What happens:
* you add a dynamic property that is non sensitive, this is saved in the flow
definition as the example below:
{code:java}
{
...
"processors": [
{
...,
"type": "org.apache.nifi.processors.standard.InvokeHTTP",
"bundle": {
"group": "org.apache.nifi",
"artifact": "nifi-standard-nar",
"version": "2025.8.5.19"
},
"properties": {
...
"example": "my non sensitive value",
...
},
"propertyDescriptors": {
...
"example": {
"name": "example",
"displayName": "example",
"identifiesControllerService": false,
"sensitive": false,
"dynamic": true
},
...
},
...
}
],
...
} {code}
* when you then restart NiFi without the processor, we do not have any
information about the property descriptors. So we will switch everything to
sensitive to not leak any information. The flow definition will become:
{code:java}
{
...
"processors": [
{
...,
"type": "org.apache.nifi.processors.standard.InvokeHTTP",
"bundle": {
"group": "org.apache.nifi",
"artifact": "nifi-standard-nar",
"version": "2025.8.5.19"
},
"properties": {
...
"example": "<encoded value>",
...
},
"propertyDescriptors": {
...
"example": {
"name": "example",
"displayName": "example",
"identifiesControllerService": false,
"sensitive": true,
"dynamic": true
},
...
},
...
}
],
...
} {code}
* when you add again the processor and restart NiFi, since it is a dynamic
property, we do not have any information coming from the bundle about that
property, we can only rely on the property descriptor in the flow definition
which has changed to sensitive, so we just keep the dynamic property sensitive.
So I'd recommend reconsidering the process where you are restarting NiFi
without the bundle of your custom NAR and see if you can change your approach
so that it does not happen.
> 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)
