This section contains description of errors concerning Network.
We use the following levels of estimated error severity:
...
Info |
---|
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). |
| This severity level implies that the process |
...
Major: This is a significant flaw that causes the system to fail. However, certain parts of the system remain functional.
...
always/usually works badly. | |||||||
| This severity level implies that the process works badly in some cases. | ||||||
| This flaw results in unfavorable behavior but the system remains functioning. |
...
| This type of flaw won’t cause any major breakdown in the system. |
...
Panel | ||||||||
---|---|---|---|---|---|---|---|---|
| ||||||||
List of identified issues in this category (click on the title to show details) |
Expand | ||
---|---|---|
| ||
|
...
|
...
Estimated severity
...
Critical
...
Examples
...
...
Suggested action
...
Expand | ||
---|---|---|
| ||
...
title | NET-003: 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
...
Critical
...
Examples
...
...
Suggested action
...
How communicated
Email correspondence with providers, testing sessions, GitHub
...