Michaël Arnauts created NIFI-13419:
--------------------------------------

             Summary: Generated API Docs is incorrect for parameterSensitivities
                 Key: NIFI-13419
                 URL: https://issues.apache.org/jira/browse/NIFI-13419
             Project: Apache NiFi
          Issue Type: Bug
          Components: Core Framework
    Affects Versions: 2.0.0-M3, 1.26.0
            Reporter: Michaël Arnauts


I've noticed something wrong with the Swagger API docs for the 
/parameter-providers/\{id}/parameters/fetch-requests endpoint.

The docs states that the reply is a ParameterProviderEntity. Going further, it 
contains a .component.parameterGroupConfigurations[0].parameterSensitivities of 
the type ParameterSensitivity. This ParameterSensitivity only allows to be 
SENSITIVE or NON_SENSITIVE:


{{        "parameterSensitivities" : {}}
{{          "type" : "object",}}
{{          "description" : "All fetched parameter names that should be 
applied.",}}
{{          "additionalProperties" : {}}
{{            "type" : "string",}}
{{            "enum" : [ "SENSITIVE", "NON_SENSITIVE" ]}}
{{          }}}
{{        },}}

However, the /parameter-providers/\{id}/parameters/fetch-requests endpoint 
returns null as a sensitivity if it hasn't been setup yet. The 
ParameterGroupConfiguration.java also states this:


{{    /**}}
{{     * @return A map from parameter name to desired sensitivity.  If the 
sensitivity is null, this indicates that the parameter}}
{{     * has not yet been configured by the user.}}
{{     */}}
{{    public Map<String, ParameterSensitivity> getParameterSensitivities() {}}
{{        return parameterSensitivities;}}
{{{}    }{}}}{{{}{}}}

This is causing issues when generating a client, since a null value won't be 
accepted, causing the parsing of the request to fail.

It seems that on Swagger 2.0, it's not supported to specify null values.

 

See also https://github.com/Chaffelson/nipyapi/pull/357#issuecomment-2178578669



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to