Hi. Thanks for the detailed description. Was able to reproduce this with the current code, and am working on a candidate fix. I've entered NIFI-10851 to track.
- https://issues.apache.org/jira/browse/NIFI-10851 On Tue, Nov 15, 2022 at 11:53 AM John McGinn via users < [email protected]> wrote: > > I'm using NiFi 1.18.0, and I use the controller services configure, enable or > disable screen, to determine what processors is using it. That way I can > determine if I can delete the controller service or not. Or, if I have to > migrate from 1 controller service to a controller service in a processor > group. (For instance, my flow gets too big, so I move the processors to a > group, but the controller services stay at the root level.) (That way I can > know for sure a controller service can get deleted because nothing is using > it, rather than deleting the controller service and having to find all > processors after the fact that are now invalid because of that.) > > > To test this, I was able to do the following. Create a processor group, add > ConvertRecord in the group, and choose a standard AvroReader as the service > at the root level. Name all of them for uniqueness. Copy the processor group, > go into the ConvertRecord and choose a new processor group level AvroReader, > and name these items uniquely as well. Go back to the root level and look at > the root AvroReader, and it was showing both ConvertRecords, even the one in > the copied group that has a new AvroReader in it. > > > I just tried that test in a 1.9.0 NiFi instance, and it didn't have the same > problem. > > John McGinn >
