Issues and Decisions

Date	Issue/Questions	Decisions
04 Jul 2024	Should dry-run be a path parameter or a query parameter?	dry-run flag should be an optional query parameter, making it part of path parameter will result in change in multiple endpoints using this feature. List of these APIs can be found below. And changing the path/endpoint by using dry-run as path parameter may impact backwards compatibility of these APIs

Overview

Currently when persisting any data in CPS the data validation is performed using the yang schema and upon successful validation the data is stored in CPS DB. But in case the data validation fails a 500 response is returned by CPS.

So, in case the data fails the validation check there is no way for the user to know the exact cause of failure. The failure is logged and can be seen in the container logs:

Logged error

{"logTimeStamp":"2024-06-19T09:28:15.909Z","logLevel":"ERROR","traceId":"a0360e58c95bc63f6ff9f873c796e51c",
"principalId":"cpsuser",
"serviceName":"cps-application",
"message":"Exception occurred",
"spanId":"81b44b7a14f8fecb",
"processId":"1",
"threadName":"qtp1504320796-24",
"class":"o.o.c.r.e.CpsRestExceptionHandler",
"exception":"\norg.onap.cps.spi.exceptions.DataValidationException: Failed to parse json data. Unsupported xpath or json data:{}
at org.onap.cps.utils.YangParserHelper.parseJsonData(YangParserHelper.java:129)
at org.onap.cps.utils.YangParserHelper.parseData(YangParserHelper.java:88)
    /....
    a lot of logged data 
    ...../
at java.base/java.lang.Thread.run(Unknown Source)\nCaused by: java.lang.IllegalStateException: Schema node with name books was not found under (urn:ietf:params:xml:ns:netconf:base:1.0)data.
at org.opendaylight.yangtools.yang.data.codec.gson.JsonParserStream.resolveNamespace(JsonParserStream.java:410)
at org.opendaylight.yangtools.yang.data.codec.gson.JsonParserStream.read(JsonParserStream.java:308)
at org.opendaylight.yangtools.yang.data.codec.gson.JsonParserStream.parse(JsonParserStream.java:193)
at org.onap.cps.utils.YangParserHelper.parseJsonData(YangParserHelper.java:122)
... 175 common frames omitted\n\n"}

This is not very helpful for the user as it does not provide proper information about the root cause of failure.

Proposal

The idea here is to have a mechanism to validate the data and throw an appropriate response with message, before the data is persisted in the database. This validation check is not meant to be limited for new data but should also extend to sub-sets of a larger data set, such as data used in case of an update operation. So based on this the following approaches are proposed to perform a validation on data:

A new endpoint to validate the JSON payload against an existing schema in CPS DB, this endpoint will only validate the data and never persist it.
A dry-run flag in the existing CPS API's which would validate the data and return a response containing the details of validation failure. This flag can be implemented to multiple CPS APIs such as POST (Create a Node), PATCH (Update a Node) and PUT (Replace a node), where we can validate the entire data or parts of data and return the exact point of failure in the validation as part of response.

Implementation Ideas

In either case the endpoint should return a RESTful response with appropriate response code and message.

Response Code: 400
Response Body: a JSON response providing details about the failure. (response body format to be finalized)

List of impacted APIs

	Name	Endpoint	Issue	Required Action
1	Create a Node	/{apiVersion}/dataspaces/{dataspace-name}/anchors/{anchor-name}/nodes	Returns 500 status on data validation failure	Return 400 status with updated and detailed error message. Updated Message: { "status": "400 BAD_REQUEST", "message": "Data Validation Failed", "Schema node with name "Node" was not found under (urn:ietf:params:xml:ns:netconf:base:1.0)data." }
2	Update Node Leaves	/{apiVersion}/dataspaces/{dataspace-name}/anchors/{anchor-name}/nodes	Returns 400 status with entire JSON payload in error message
3	Replace Nodes	/{apiVersion}/dataspaces/{dataspace-name}/anchors/{anchor-name}/nodes	Returns 400 status with entire JSON payload in error message
4	Add List Element	/{apiVersion}/dataspaces/{dataspace-name}/anchors/{anchor-name}/list-nodes	Returns 500 status on data validation failure
5	Replace List element	/{apiVersion}/dataspaces/{dataspace-name}/anchors/{anchor-name}/list-nodes	Returns 400 status with entire JSON payload in error message

Example

The following example shows the expected changes to existing APIs to implement a dry-run flag:

#

API

Request parameters

Response Codes

Scenarios

1

Create a Node:

/v2/dataspaces/{dataspace-name}/anchors/{anchor-name}/nodes

Parameter Name	In	Required	Description
dataspace-name	Path	true	dataspace name
anchor-name	Path	true	anchor name
xpath	Query	true	xpath of node
dry-run	Query	false	flag to enable or disable data validation (set to false by default)

200 (OK)
- success
400
- dataspace not found
  DataspaceNotFoundException
- anchor not found
  AnchorNotFoundException
- Data node not found
  DataNodeNotFoundException
- invalid xpath
  CpsPathException
500
- unexpected error

Scenario 1: dry run set to false

In this case there will be no functional change in the APIs, and they would return appropriate response codes with messages in case of any failure.
In case of successful validation, the data will be persisted, and a 200-response code is returned with nothing in response body
In case of validation failure, the data validation error is returned with appropriate message and a 400-response code.

Scenario 2: dry run set to true

In this case the APIs will return the same response codes. The only difference will be:
- in case data validation passes, then it would return a 200-response code without any response body, and the data will not be persisted in case of POST operation or modified in case of PUT/PATCH operations.
- In case of validation failure, the data validation error is returned with appropriate message and a 400-response code.

CPS-2305 Data Validation Report Proposal