pvillard31 opened a new pull request, #11086: URL: https://github.com/apache/nifi/pull/11086
# Summary NIFI-15776 - Classify migration-added static properties as environmental changes in versioned flows When a component's bundle version changes (e.g., NiFi upgrade), property migration code may add new statically-defined properties that did not exist in the registry snapshot. These `PROPERTY_ADDED` differences were previously treated as local modifications, which caused two problems: 1. Versioned process groups appeared dirty after a bundle upgrade, even though the changes were entirely due to migration — not user action. 2. After importing (checking out) an older flow version on a newer NiFi, the flow was marked as locally modified, blocking upgrades to newer flow versions. This happened because `discoverCompatibleBundles` resolves bundle references in-place on the flow snapshot before it is stored as the VCI baseline, eliminating `BUNDLE_CHANGED` differences from the dirty-detection comparison while leaving migration-added `PROPERTY_ADDED` differences unfiltered. This change adds a new environmental change filter `isNewStaticPropertyOnComponent` to `FlowDifferenceFilters`. It classifies a `PROPERTY_ADDED` difference as environmental when the added property is a statically-defined property on the component (i.e., declared in the component's code via `getPropertyDescriptors()`). Since users cannot add static properties — they can only modify values of existing ones — a `PROPERTY_ADDED` for a static property always indicates a component code change (migration/upgrade), not a user modification. **Trade-off:** If a user subsequently edits a migration-added property, the diff relative to the registry remains `PROPERTY_ADDED`, so the edit is also classified as environmental and will not make the flow dirty on its own. However, the change remains visible in the "Show Local Changes" environmental view, and when the user commits for any other reason, the full flow (including the edited property) is saved to the registry. This should be a rare enough scenario to be an acceptable trade-off. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) 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](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) 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](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
