[ 
https://issues.apache.org/jira/browse/NIFI-16305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Villard resolved NIFI-16305.
-----------------------------------
    Fix Version/s: 2.12.0
         Assignee: Mark Payne
       Resolution: Fixed

> 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
>            Assignee: Mark Payne
>            Priority: Major
>             Fix For: 2.12.0
>
>          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)

Reply via email to