Yuanhao Zhu created NIFI-15694:
----------------------------------
Summary: Processor group version issue with updated
processor/controller service attribute from Nifi version
Key: NIFI-15694
URL: https://issues.apache.org/jira/browse/NIFI-15694
Project: Apache NiFi
Issue Type: Improvement
Reporter: Yuanhao Zhu
Attachments: image-2026-03-10-15-21-17-700.png
For the past few Nifi version upgrades (2.5 - 2.6, 2.6 - 2.8), we have noticed
that sometimes a new release contains changes to the existing
processor/controller services attribute. And for a processor group under
version control, in this case the upgrade of nifi version will result in
changes like:
!image-2026-03-10-15-21-17-700.png!
But under the hood the value of these property stays actually the same. And
this brings a problem if you have multiple stages.
e.g. Assume we have 2 stages, dev and prod, they both have a processor group A
that is imported from the same flow in the same registry. And the version of
both flows is the latest version 16. Now I upgrade the dev nifi instance to the
next version, say 2.8.0, it introduces the changes mentioned above. So, we
commit those changes into nifi registry, which made the current version of
group A to be 17 in the registry now. And here comes the problem, if I upgrade
prod nifi instance also to 2.8.0, then the flow A on prod will be in status
conflicted, because though essentially on prod it also has the changes that's
introduced by nifi version upgrade, the version number of the flow definition
on prod is still 16 and nifi registry thinks this is a conflict. Also here you
cannot roll back those changes introduced by upgrade
Currently, the only way that we think of to not have to delete the flow on prod
and reimport from registry is that we have a script that manually change such a
flow definition version number to the latest one.
And we think this is really not ideal, since it is not really a version
conflict, and we need to intervene manually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
