General

Levels of estimated error severity.

If an error is present in the context of an API (or endpoint), it applies only to that API (or endpoint).

CRITICAL	This severity level implies that the process always/usually works badly.
MAJOR	This severity level implies that the process works badly in some cases.
MEDIUM	This flaw results in unfavorable behavior but the system remains functioning.
LOW	This type of flaw won’t cause any major breakdown in the system.

List of identified issues in this category (click on the title to show details)

GEN-001: Allowing users to enter incorrect data

Description	If a specification requires some field to be in a specific format, applications should have proper server-side validation to prevent their users from entering incorrect data. Perfect examples are fields where the value is expected to be an email or a URL.
Estimated severity	MAJOR
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 15 providers in PROD (link1, link2)

GEN-002: Missing required fields

Description	Fields specified as required must be provided in the API response. Such errors in many cases can be easily detected in your tests by validating your responses with the XSD schemas. You can also use validators available in the DEV Registry Service.
Estimated severity	CRITICAL
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 11 providers in PROD

GEN-003: Attaching request body in error-response

Description	A provider attaches full request body and parameters in error-responses in the Stats Portal
Estimated severity	MEDIUM
Examples
Suggested action	A provider should stop doing this, because it might result in leaking private data when such errors are reported to the Stats Portal
How communicated	Monitoring system Problem occurred for at least 2 providers in PROD (link1, link2) and 1 other in DEV

GEN-004: Attaching stack trace in error-response

Description	Full stack traces aren't helpful to other partners and are only making reports in the Stats Portal less readable.
Estimated severity	LOW
Examples
Suggested action	In case of unknown errors it is enough to return some generic message, e.g. "Something went wrong. Administrators have been notified. We'll try to fix it ASAP.", as suggested in the specification.
How communicated	Monitoring system Problem occurred for at least 2 providers in PROD (link1, link2).

GEN-005: Wrong answer to a CNR or GET as part of CNR

Description	According to specification “Once you receive a change notification, you respond with HTTP 200, and add the received identifiers to a queue. Later on, in the background, you will attempt to update your locally stored information on the received entities (e.g. by calling the `get` endpoints of the APIs which describe this entity). You SHOULD NOT try to refresh your data before sending your CNR API response. Refreshing the data (e.g. calling the `get` endpoint) is a separate operation, and the result of this operation MUST NOT influence the HTTP response of your CNR API” A number of partner send some error codes instead.
Estimated severity	MAJOR
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Email correspondence with providers, testing sessions, GitHub This error was encountered in a number of mobility systems