mcgilman opened a new pull request, #11200: URL: https://github.com/apache/nifi/pull/11200
…or connector verification. # Summary [NIFI-15902](https://issues.apache.org/jira/browse/NIFI-15902) When a connector configuration step is verified on a clustered NiFi, the `subject` field on each `ConfigVerificationResultDTO` is dropped during cluster aggregation. As a result, clients receive verification results with a populated step name, outcome, and explanation but a `null` subject, even though every node produced a subject for the failing property. The cause is in `ConfigVerificationResultMerger.computeAggregateResults()`, which constructs a brand new aggregate DTO and copies only `verificationStepName`, `outcome`, and `explanation` from the selected node result. The `subject` is silently lost. This change copies the `subject` from the selected node result onto the aggregate DTO so it is returned to the client unchanged. The "selected" result is already chosen as the worst-outcome result (FAILED > SKIPPED > SUCCESSFUL), which means the surfaced subject corresponds to the verification result the user actually needs to act on. The same `ConfigVerificationResultMerger` is also used by `VerifyConfigEndpointMerger` (processors, controller services, reporting tasks, parameter providers, flow analysis rules), so any of those endpoints whose upstream DTOs include a subject will now also preserve it through cluster aggregation. Today their per-DAO DTO converters do not set `subject`, so there is no behavior change for those endpoints; only the connector verification path observes a visible difference. ## Behavior - Single-node responses: explanation, outcome, step name, and subject are all preserved (unchanged). - Multi-node clusters where all nodes agree: the agreed subject is returned (unchanged step name/outcome/explanation handling). - Multi-node clusters where nodes disagree: the subject from the worst-outcome (selected) result is returned, consistent with how the explanation prefix is already chosen. ## Tests `ConfigVerificationResultMergerTest` adds three cases covering the new behavior: - `testSingleNodeSubjectPreserved` - single-node failed result keeps its subject through the merge. - `testMultiNodeAgreeSubjectPreserved` - two nodes agreeing on a successful result keep the shared subject. - `testMultiNodeDisagreeSubjectFromSelectedResult` - when one node succeeds and another fails, the merged result carries the failing node's subject, matching the worst-outcome selection that already governs the merged outcome and explanation. -- 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]
