[jira] [Comment Edited] (NIFI-14599) Parameter provider invalid revision issue

["Yuanhao Zhu (Jira)" <ji...@apache.org>]

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

Yuanhao Zhu edited comment on NIFI-14599 at 6/2/25 7:36 AM:
------------------------------------------------------------

Now I can actually reproduce it properly, the problem is that if we try to add secrets from the source(in our case it's in the azure keyvault) that belongs to different parameter context, at the same time, and let the NIFI pull the secrets using AzureKeyvaultParameterProvider, then this issue will occur. The problem is that when there are more than one parameter context that needs to be updated when a parameter provider fetches the parameter and applies updates, the nifi will try to use the same revision number for multiple parameter provider revision update. see the logs below:
!image-2025-06-02-09-24-01-141.png!

 

Edit: As I have indeed enabled all logs from revision package to debug, I didn't see the parameter context revision to be updated but only the parameter provider(The component with id ending with 55a7 is the azure parameter provider), I'm wondering: is it trying to update the parameter provider while this is not even the expected behavior?


was (Author: JIRAUSER305688):
Now I can actually reproduce it properly, the problem is that if we try to add secrets from the source(in our case it's in the azure keyvault) that belongs to different parameter context, at the same time, and let the NIFI pull the secrets using AzureKeyvaultParameterProvider, then this issue will occur. The problem is that when there are more than one parameter context that needs to be updated when a parameter provider fetches the parameter and applies updates, the nifi will try to use the same revision number for multiple parameter provider revision update. see the logs below:
!image-2025-06-02-09-24-01-141.png!

> Parameter provider invalid revision issue
> -----------------------------------------
>
>                 Key: NIFI-14599
>                 URL: https://issues.apache.org/jira/browse/NIFI-14599
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 2.1.0, 2.2.0, 2.3.0, 2.4.0
>            Reporter: Yuanhao Zhu
>            Priority: Major
>         Attachments: image-2025-06-02-09-24-01-141.png
>
>
> We recently upgrade to nifi 2.4.0 from 1.x and have noticed something weird about the parameter provider in 2.x. From time to time, for some reason, the parameter provider will complain about invalid revision given when fetching for parameters with nifi-cli. Specifically we are using AzureKeyvaultParameterProvider. And once this happens, the only way to get rid of it is the re-creation of the parameter provider.
> See the screenshot 
> !https://community.cloudera.com/t5/image/serverpage/image-id/45570i701517E88FD12C48/image-size/large/is-moderation-mode/true?v=v2&px=999!
> And it looks like the revision manager was messed up that every time the new revision is always one version below, we are running nifi in a standalone mode and consecutively triggering of the parameter fetch will constantly get the invalid revision(each time the revision is up by 1) until the parameter provider is recreated, even restarting nifi won't help. I'm also quite sure there is only one person sending request to fetch for parameter and attempt to change the parameter provider at the same time so no concurrent operation. 
>  
> And once this problem happens, fetching parameters from UI also does not work, it would just fail silently and the value of the secrets remains unchanged.
>  
> Also FYI, this never happened in 1.x
>  
> Another FYI, if we restart the nifi container, it does not go away, and the revision number in the complaint will start over from 0
>  
> Still have no idea how to reproduce it though, but will keep trying and log the activities in this ticket



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