[
https://issues.apache.org/jira/browse/NIFI-14599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18009873#comment-18009873
]
Aljaz Hericko commented on NIFI-14599:
--------------------------------------
Agree, it's a huge problem for us as well. We have some workarounds and
guidelines for developers now in place to avoid the issue, but as we have
multiple teams working on NiFi and 50+ contexts, it's bound to happen and
requires a bit of effort to find the problematic context and doing the
workaround for it.
I can give a more detailed description of the reproduction case, as we found
two problematic scenarios.
The first one was already described above and occurs when you remove a
parameter from the source. A Jira is already open for it -
https://issues.apache.org/jira/browse/NIFI-14269?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=17933338#comment-17933338
The second case is if you have different environments for development and
production and use the parameter contexts with the same name and same named
providers, but reference different parameters on the source (for example, to
make it so dev uses dev credentials and prod uses prod credentials). When
importing the flows via flow registry, if a flow has a parameter inside which
is not available in that environment, it will have the same consequences as
option 1. It will think it has to remove the parameter as it is not available
on the source, but since it is not able to remove it, nothing will happen. And
since on every refetch it will try to update the same parameter context and
fail on others, the parameter context update will not work until the missing
parameter is added to the source in that environment as well.
Most often, this occurs to us when someone is developing in the development
environment and adds a new parameter in the source. When another flow using the
same context is committed and deployed to production, this parameter then
causes all the parameter context updates to stop working.
Seems like this is something that will happen to pretty much everyone using
parameter contexts and multiple environments so hopefully someone can look into
it.
> 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
>
> Steps to reproduce:
> # Add secrets for multiple groups from the source for the same parameter
> provider. e.g. add one secret where group-name set to a and one secret where
> group-name set to b in Azure keyvault.
> # In Nifi, trigger the existing parameter provider to fetch and update
> parameter
> Now you should see that the parameter provider failed to be updated in the
> logs
>
> I think the exact problem is that when there are more than one parameter
> contexts related to one parameter provider ,the update for parameter contexts
> related to a parameter provider is always based on the revision given in the
> request, after the first parameter context update, the other parameter
> context update will still try to make the change based on the outdated
> revision given in the request
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
