mcgilman opened a new pull request, #11251: URL: https://github.com/apache/nifi/pull/11251
…PI errors present. # Summary [NIFI-15941](https://issues.apache.org/jira/browse/NIFI-15941) Allow users to re-submit a Verify request in the Connector wizard after a prior backend (API) verification failure without first having to modify form values. ## Problem The `SharedConnectorConfigurationStep` "Verify" button is gated by `stepForm.valid`. When a previous Verify call returned per-field errors, the wizard store projected those errors onto the corresponding form controls under a `verificationError` key via `verificationErrorValidator`. That made `stepForm.valid === false`, which permanently blocked the Verify button — even though the failures are typically caused by external conditions (network, permissions, mis-provisioned external resource, etc.) that the user cannot resolve by editing the form. The only workaround was to mutate an unrelated value to trigger an error clear, which is a poor user experience. ## Change - Introduce a module-level constant `VERIFICATION_ERROR_KEY = 'verificationError'` and route `verificationErrorValidator`'s error key through it, so the contract between this validator and the verify gate is named in one place. The matching template literal in `connector-property-input.component.html` is documented next to the constant. - Add a private `isClientValid()` predicate that walks the form controls and treats a control as "valid for verify" if it is disabled (mirrors `FormGroup.valid` behavior for dependency-hidden properties), valid, or carries only the `verificationError` key. `canVerify` and `onVerify()` now consult `isClientValid()` instead of `stepForm.valid`, so prior API verification errors no longer block Verify while genuine client-side errors (`required`, `pattern`, etc.) still do. - Rewrite `updateFormValidityForVerificationErrors()` to iterate every form control rather than only the keys in the current error signal. Previously, when the signal cleared (successful verify, verify start), controls still carrying a stale `verificationError` from a prior subscription emission were never re-validated, so the error key lingered visually. The new version handles both directions: new errors and stale errors. ## Tests Added a `verify gate` describe block to `connector-configuration-step.component.spec.ts` with 10 cases covering: - Clean form: `canVerify === true`. - API-only errors: `canVerify === true`, `stepForm.valid === false`, control reports `verificationError`. - Required client error: `canVerify === false`. - Hidden-dependent property that would otherwise be required: `canVerify === true` (disabled control bypassed, mirroring `FormGroup.valid`). - Mixed client + API errors: `canVerify === false` (client error wins). - In-flight verify: `canVerify === false`. - `onVerify()` dispatches `verifyStep` when only API errors remain. - `onVerify()` does not dispatch when a client error exists. - Stale `verificationError` is cleared when the store signal empties (successful verify path). - Per-control reconciliation when the signal transitions from `{host: ...}` to `{port: ...}`. -- 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]
