[
https://issues.apache.org/jira/browse/NIFI-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18112419#comment-18112419
]
ASF subversion and git services commented on NIFI-16305:
--------------------------------------------------------
Commit e411fa647e1460967b3bf6cbbb8147b2e90bd7e3 in nifi's branch
refs/heads/main from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e411fa647e1 ]
NIFI-16305 Fix Connector mock framework behavior (#11635)
> Fix startup error propagation, flow snapshot metadata, and secret lookup in
> Connector mock framework
> ----------------------------------------------------------------------------------------------------
>
> Key: NIFI-16305
> URL: https://issues.apache.org/jira/browse/NIFI-16305
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The nifi-connector-mock-bundle test framework currently hides failed startup
> attempts, produces inaccurate parameter snapshots, and cannot resolve secrets
> using the fully qualified names returned by discovery.
> h3. Startup failures are discarded
> *Reproduction*
> Build a runner for an invalid Connector, such as the existing
> MissingBundleConnector, and call startConnector(). The call returns normally
> even though the Connector cannot start.
> StandardConnectorMockServer.startConnector() discards the Future returned by
> ConnectorNode.start(). Validation and configuration-resolution exceptions are
> captured in that Future, leaving the test without the failure cause.
> *Expected behavior*
> The runner reports a failed startup with its underlying cause instead of
> appearing successful or requiring a later ingestion timeout to reveal the
> failure.
> *Acceptance tests*
> * An invalid Connector reports its startup failure through the runner.
> * A Connector whose configuration cannot resolve reports its startup failure
> through the runner.
> * A valid Connector still starts successfully.
> h3. Flow snapshots lose asset references and misreport parameter metadata
> *Reproduction*
> Snapshot a parameter context containing the following:
> * A sensitive parameter with provided=false. The snapshot reports
> provided=true.
> * A nonsensitive parameter with provided=true. The snapshot reports
> provided=false.
> * A parameter referencing an asset. The snapshot loses referencedAssets and
> instead contains the resolved local file path.
> StandardConnectorMockServer.createVersionedParameterContext() sets provided
> from the sensitivity flag and does not map referenced assets. Both active and
> working snapshots use this helper.
> *Expected behavior*
> Snapshots preserve the actual provided flag and asset references consistently
> with the production flow mapper, while continuing to omit sensitive values.
> *Acceptance tests*
> * Both snapshot APIs preserve asset identifiers and names.
> * Both snapshot APIs preserve all combinations of sensitive and provided
> metadata.
> * Sensitive values remain omitted.
> h3. Discovered secret names cannot be resolved
> *Reproduction*
> Register password using addSecret(). Discovery returns a secret with the
> fully qualified name Default.password. Resolve a SecretReference using that
> provider and fully qualified name. Lookup returns no secret.
> ConnectorTestRunnerSecretProvider.getAllSecrets() adds the Default. prefix,
> but getSecrets() looks up the supplied fully qualified name directly in a map
> keyed by the unqualified name. The createSecretReference() convenience path
> masks this inconsistency by using the bare name.
> *Expected behavior*
> A secret returned by discovery can be resolved using its advertised provider
> and fully qualified name. References produced by createSecretReference() also
> resolve consistently.
> *Acceptance tests*
> * Cover discovery-to-reference-to-lookup round trips.
> * Cover references produced by the runner helper.
> * Cover secret names containing dots.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
