NIFI-16326 Corrected subsequent Parameter Context inheritance updates

[mattcasters]

Summary

NIFI-16326 Subsequent Parameter Context inheritance changes do not update effective parameter values.

The first inheritance change on a Parameter Context (reorder, add, or remove) updates effective values as expected. Later inheritance changes update the configured inheritance list, but NiFi continues using the value that became effective after the first change. Process Groups and components bound to that context see the same stale value.

This happens because Parameter Context update analysis injects effective inherited Parameter DTOs into the request so referencing components can be identified. Those DTOs were persisted as local Parameters whenever inherited was not explicitly true. A local Parameter then shadows inheritance, so later reorders and add/remove operations cannot change the effective value.

StandardParameterContextDAO.getParameters() now omits inherited Parameters from local persistence when:

• inherited is true, or
• inherited is unset and the Parameter's source context is not the context being updated

An explicit local override (inherited=false) is still accepted.

Coverage includes unit tests for repeated reorder and add/remove on StandardParameterContext, DAO tests for injected effective Parameters with and without the inherited flag, and system tests that replay the Jira reproduction through the REST update API.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• ./mvnw -P contrib-check -DskipTests package completed on the changed modules and their reactor dependencies (JDK 21)
  • JDK 21
  • JDK 25
• Unit tests: TestStandardParameterContext (inheritance reorder/add-remove), TestStandardParameterContextDAO (11 tests)

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[pvillard31]

Hey @mattcasters

I feel like the described issue may have been already fixed on the main branch with NIFI-16226. Are you able to reproduce your issue on a build from the main branch? If you cannot run a test, I'm happy to give it a try if you have specific steps reproducing the problem on your side.

[mattcasters]

Thanks Pierre.

The PR is based on current main (rebased onto NIFI-16319 / b6a04999e8 at open time). That already includes both NIFI-16226 (778dd665b6) and NIFI-16286 (14fa8a2fb0). main has since gained only NIFI-16320, which is unrelated.

NIFI-16326 was filed against 2.11.0, which does not have NIFI-16226 (that landed for 2.12.0). I agree NIFI-16226 is in the same area: update analysis was reclassifying inherited Parameters as local. After that change, setEffectiveParameterUpdates() sets inherited from the source context, and getParameters() already skipped inherited=true. For the common REST path (empty parameter list, or inherited Parameters with the flag set), that should already prevent the first inheritance change from being saved as a local Parameter on main.

What this PR still covers on current main is the apply path when the effective value is present on the update DTO without inherited=true, but with a source Parameter Context other than the one being updated. In that case main still persists the value locally, and later reorders / add-remove keep the stale effective value. That is the DAO test testSubsequentInheritanceReorderDoesNotPersistEffectiveValueWhenInheritedFlagMissing.

I have not re-run the original UI steps against a vanilla main build. If you already see the Jira reproduction fixed on main by NIFI-16226, I am happy to close this, or keep the extra DAO guard plus the Jira-step tests as regression coverage.

[klasvo]

This issue seems to be related to the one I filed some days ago: https://issues.apache.org/jira/browse/NIFI-16278
Creating inheritances makes inherited parameters local ones

This is easily reproducible. From the issue:

1. Create a parameter context named "test" without parameters
2. Create a parameter context named "test2" with one parameter
3. Edit parameter context "test" to inherit from "test2" and save
4. Edit parameter context "test", remove the inheritance from "test2" and save
5. Edit "test" again and notice that the parameter from "test2" is still present and shown as inherited, while no inheritance is present
6. Look into current flow.json and notice that parameter context "test" has the parameter from "test2" as local parameter set
7. Optional: delete parameter context "test2", log out and in again and notice that the parameter context page cannot be opened anymore
8. Restart Nifi to fix the "ghostly" inheritance and notice that parameter context "test" now has a local parameter

However, I am not able to build from the branch, so I cannot test whether this change solves my issue

Cheers
Volker

[pvillard31]

I just executed the steps described above and everything works as expected on the main branch (release candidate for NiFi 2.12.0 that is being voted right now). I believe the issue was fixed with NIFI-16226.