CPS-1865: Common Error Reporting with Additional Details

References

CPS-1865 - Getting issue details... STATUS

Requirements

Functional

	Interface	Requirement	Additional Information	Signoff
1	CPS-E-05e	NCMP will define (and publish) additional error information details to be implemented by DMI plugins NCMP shall forward any such details where applicable

Characteristics

No specific characteristics but obviously the additional error information should not (significantly) impact existing throughput negatively.

Out-of-scope

context-type:application/problem+json. As per decision #1 this is no longer required

Issues & Decisions

Issue

Notes

Decision

1

Use of context-type:application/problem+json

Toine Siebelink raised several concerns:

when is a response exactly a 'problem'. Not clear for partial error-scenarios or answers like 'rejected'
context-type is simply the WRONG field to say anything about the status of the content it should only define formatting.

18 Oct 2023 kieran mccarthy agreed during weekly stakeholder meeting will NOT be required for events (or legacy API call).
It might be used in the future

2

Scope

Scope need to be clearly defined. it could cover both existing and new (ongoing impl) interfaces I suggest we build it up and this epic can continue in future releases. With different priorities for different user stories.

Candidates (not a compleet list)

Async responses from (bulk) dataOperations
Async response from CM Data Notification Subscriptions
Existing synchronous data requests
(initial) Registration request responses

3

'other' ie. undefined keys v. predefined(and documented) keys

if 'other' is a key-value pair with any name the schema cannot be defined to have at least one predefined key-value in the map (retryAfter). It has to be either free for all map entries OR a defined structure! At best we can desribe the map if it is NOT defined in the schema but then we need to hardcode validation!

Impl. Proposal

Additional Error Info Structure

Rows 1-13 describe the exiting data structure
Rows 14-18 Proposed additional (error) fields

	Element	Name	Parent	Type	Mandatory/ Optional	Description	Format	(example) Value
1	Header	id		String	Mandatory	random id for cloud event header. UUID is suggested
2		source		String	Mandatory	source of information
3		specversion		String	Mandatory	cloud event version spec	fixed value	1.0
4		type		String	Mandatory	type of event	fixed value
5		dataschema		String	Mandatory	data schema	fixed value
6		correlationid		String	Mandatory		<cmhandle-id>
7	Payload	data		Object	Mandatory	The actual data payload. Details will be provided below.	3GPP TS 28.532 standard
8		responses	data	Object[]	Mandatory
9		operationId	responses[i]	String	Mandatory
10		ids	responses[i]	String[]	Mandatory
11		statusCode	responses[i]	Integer	Mandatory
12		statusMessage	responses[i]	String	Mandatory
13		result	responses[i]	Object	Optional		application/yang-data+json
14		errorInfo	responses[i]	Object	Optional	additional error information for debug and retry purposes, present in case of failure error code	<name>
15		message	errorInfo	String	Optional	message coming from EMS or node
16		correctiveAction	errorInfo	Map	Optional	key-value pairs of possible recourse action the client can take in case of error
17		retryAfter	correctiveAction	<String,Int>	Optional	seconds to wait before retry		"retryAfter" : 60
18		other	correctiveAction	<String,object>	Optional	non-specific key-value pairs driven by ems or node		“other”: {}