tried committing with no parameter context as you suggested and it's working. The issue now is that in order to set parameter contexts I have to do it manually, one by one, for each versioned process group within my instances. So I commit on my "master" group, with no context, then I stop my instance, change version, and have to go into the instance and change contexts in each process group of my instance. And I have to do this for quite a few instances and for quite a few "master" flows. Sure it works but this is such a pain! In the past I would complain about having to change versions on each instance individually, but this is a whole new level of tedium and inefficiency. Plus my index finger is hurting quite a lot.
On 2025/11/10 14:21:09 "Greene (US), Geoffrey N via users" wrote: > Its not just you. I have the same issue... > > In my case I have the following dev/prod parameter contexts > D1, D2, and D3 all inherit from D > P1 P2 and P3 all inherit from P > > I also have two nifi implementations,Dev, and Prod. > They all talk to the same nifi registry. > > I've discovered that sometimes, hen I upgrade a flow from Dev to Prod, > If I keep the parameter context set to D1, D2 or D3 when I commit, > Then when I update Prod, all of a sudden P1 inherits from D (which is clearly > wrong). > > My workaround for now is to 1) manually check the parameter contexts every > time I update and 2) NEVER commit a process group with a parameter context > set. This seems to take care of it. > > Geoffrey Greene > ATF / Senior Software Ninjaneer > > > From: Paminos Sym <[email protected]> > Sent: Monday, November 10, 2025 6:18 AM > To: [email protected] > Subject: [EXTERNAL] NiFi Registry issue when upgrading to 2.6.0 from 2.2.0 > > EXT email: be mindful of links/attachments. > > > Hello everyone, > > Let me start by describing how we use NiFi: We have many different types of > flows of which exist multiple instances, each with its own parameter context. > For example, flow A may have 15 instances and flow B another 15. Each flow is > version controlled using NiFi Registry and is composed of a few process > groups that are usually each also version controlled. Flows go into a flow > bucket, while the process groups they are made up of go into a process group > bucket. Essentially it is similar to having an Abstract object (flow) > composed of other abstract objects (internal process groups). Every time we > create an instance, this object and the ones composing it are all > instantiated by getting parameters. > > [cid:[email protected]] > > Until our recent upgrade to 2.6.0 this was functional and working mostly as > expected. To create a new instance of Flow A I would get one from the > registry, change the name, create a new parameter context, and I very quickly > had a new clone of flow A with different parameters. Now when I get a new > instance from the registry with "Keep existing Parameter Contexts" checked I > get this error: > [cid:[email protected]] > (I can't share the parameter context names) > I believe this has something to do with how our parameter contexts are > organized. There is a "Root Parameters" context which both Flow A and Flow B > inherit. Flow A and Flow B both have their "super" contexts (like > "super-flow-a-parameters") which inherit the Root Parameters context, and the > super contexts are inherited by the instance specific context. Then each > instance and the process groups within will use the instance specific > context. This base.sourceType parameter belongs to an instance specific > parameter context and is inherited from the root parameters context, and is > blocking my operation, but the issue is that there is no reason for this > parameter to be updated when I create a group. Creating a new group shouldn't > change the value of a parameter, so why is it trying to update this one? > > To bypass this I create the group with the "Keep existing Parameter Contexts" > unchecked, however this creates copies of some contexts (e.g. > "flow-a-instanceA (1)", "flow-a-instanceA (2)"). > > [cid:[email protected]] > > After deleting the superfluous copies of the parameter contexts and creating > the new instance's parameters I try to change the whole group's parameters. > Reminder: This is the instance's group, which is under Flow A's version > control, and contains process groups that are also version controlled. > Before, to do this I would simply click "configure" on my group, select my > parameter context, select "Apply Recursively", and after pressing apply it > would work as expected. Now I get an error: > [cid:[email protected]] > This seems very strange, not only because this used to work without any > issue, but also because switching parameter contexts on a versioned flow > being a problem seems completely wrong. My work-around for the time being is > to uncheck "Apply Recursively" and manually apply the correct context in each > of the internal process groups, which is time consuming and error prone. > > The final issue I have encountered thus far is more minor. Previously, if I > made a change to a versioned flow and wanted to update every flow with that > version I would simply go to each one, running or not, and select "change > version". Though time consuming it was a frictionless procedure. Now I get an > error similar to the first one, and the work-around is to stop the flow I'm > updating, change flow version, and start it again. This makes it even more > time consuming but at least it's more manageable. > > I find it hard to believe that this is intended behaviour. Is it because we > updated from 2.2.0 straight to 2.6.0? Is this something others have > experienced? > > Any help or explanation would be greatly appreciated, thank you. > > Epameinondas Symeonidis, > Ianic S.A. > >
