[
https://issues.apache.org/jira/browse/NIFI-14599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18010498#comment-18010498
]
Bill Kinzel commented on NIFI-14599:
------------------------------------
[~pvillard]
I applied the patch for {*}NIFI-14269{*}, and it successfully resolved the
issue related to parameter deletion. However, I'm still encountering
inconsistent behavior related to {*}Parameter Providers and Parameter
Contexts{*}.
Specifically:
* On restart, not all secrets are fetched correctly — {*}parameter values are
sometimes empty{*}, though the {*}keys are consistently imported{*}.
* When updating or adding new secrets, the {*}fetch operation frequently
results in missing values{*}, even though the associated parameter keys appear
as expected.
* I've observed that modifying the *timeout property* on the parameter
provider before performing a fetch seems to act as a workaround. Changing the
timeout appears to "sync" or refresh the provider's state, after which the
values are reliably fetched again.
As part of troubleshooting, I also removed the *SSL Context Service* from the
parameter provider definition — just eliminating some unnecessary setup. This
didn’t appear to affect the behavior but simplified the configuration.
This workaround has made things stable for now, but I haven’t been able to
identify a consistent pattern to establish a root cause. It seems like there
may be a caching or state synchronization issue — possibly version-related —
that isn’t being properly triggered on standard fetch operations or restarts.
> 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, 2.5.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)
