Skip to content

NIFI-16114 Fix version change bug when controller service property has a parameter reference#11432

Open
esecules wants to merge 1 commit into
apache:mainfrom
esecules:NIFI-16114-fix
Open

NIFI-16114 Fix version change bug when controller service property has a parameter reference#11432
esecules wants to merge 1 commit into
apache:mainfrom
esecules:NIFI-16114-fix

Conversation

@esecules

@esecules esecules commented Jul 14, 2026

Copy link
Copy Markdown
Contributor

Summary

NIFI-16114 Fix version change bug that caused the controller service properties which have parameter values to have those parameters dereferenced leading to immediate "local changes" in my versioned flow.

Tracking

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

Issue Tracking

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

  • Build completed using ./mvnw clean install -P contrib-check
    • JDK 21
    • JDK 25

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

@esecules
esecules force-pushed the NIFI-16114-fix branch 2 times, most recently from 233d128 to 493021a Compare July 14, 2026 22:49

@pvillard31 pvillard31 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make sure that commit/PR follows the rules for the checks to execute properly? Also, did you consider a system test for it?

@esecules esecules changed the title [NIFI-16114] Fix version change bug when controller service property has a parameter reference NIFI-16114 Fix version change bug when controller service property has a parameter reference Jul 16, 2026
@esecules

Copy link
Copy Markdown
Contributor Author

Can you make sure that commit/PR follows the rules for the checks to execute properly? Also, did you consider a system test for it?

@pvillard31 thanks for having a look. I've added a system test and I fixed up the commit message and PR title to match the rules.

|| (versionedDescriptor != null && versionedDescriptor.isSensitive());

final String proposedValue = proposedProperties.get(propertyName);
final ParameterParser parameterParser = new ExpressionLanguageAgnosticParameterParser();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This parser is stateless and is created for every property on every synchronized component. Could it be a private static final field, or created once outside the loop?


final String proposedValue = proposedProperties.get(propertyName);
final ParameterParser parameterParser = new ExpressionLanguageAgnosticParameterParser();
final boolean proposedReferencingParameter = parameterParser.parseTokens(proposedValue).iterator().hasNext();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

proposedReferencingParameter is only read inside the referencesService branch. Could the parseTokens call move into that branch so non controller service properties are not parsed?


final String proposedValue = proposedProperties.get(propertyName);
final ParameterParser parameterParser = new ExpressionLanguageAgnosticParameterParser();
final boolean proposedReferencingParameter = parameterParser.parseTokens(proposedValue).iterator().hasNext();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would toReferenceList().isEmpty() be more precise here than iterator().hasNext(), since the iterator also returns true for escape only tokens such as ##?

}

@Test
@SuppressWarnings("unchecked")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The test class already has a shared type safe propertiesCaptor field built with ArgumentCaptor.captor(). Could the new tests reuse it (or use captor()) so the @SuppressWarnings(unchecked) is not needed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants