Repository navigation
QoS B: Improve Error Handling Description - #145
Conversation
Masa8106
changed the title
|
|
||
| - If the subject can be identified from the access token and the optional `device` object is also included in the request, then the server will return an error with the `422 UNNECESSARY_IDENTIFIER` error code. This will be the case even if the same device is identified by these two methods, as the server is unable to make this comparison. | ||
|
|
||
| - If a request value is outside the valid range supported by the operator, typical examples include a start time or ports, then the server will return an error with the `400 OUT_OF_RANGE` error code. |
There was a problem hiding this comment.
These bullets are within the <!-- CAMARA:MANDATORY:identifying-device-from-access-token:BEGIN --> to <!-- CAMARA:MANDATORY:identifying-device-from-access-token:END --> block and will eventually be overwritten by the RM process, you should move them outside the block
There was a problem hiding this comment.
They actually must be outside the block as otherwise the validation will warn about the drift (P-027). The block must be a 1:1 copy of the Commonalities template. Between line 65 and 69 would be ok.
But I would anyway put this kind of information rather into the description of the error response example and/or near to operation which will raise this error ... here it is somehow without context.
There was a problem hiding this comment.
Thank you for your comments. I see your point. Since I couldn't find a suitable place to add this information near each error response, I tried to add it to the “Additional CAMARA error responses” paragraph.
|
|
||
| - A QoS booking is a reservation for an App-flow between a specific device and a specific application server, a specific time window and, where relevant, a specific service area. An App-flow is expected to have at most one active booking at a time. If the client attempts to create a duplicate or overlapping booking for the same flow, then the server will return a `409 ALREADY_EXISTS` error code. | ||
|
|
||
| - If the requested area is syntactically valid but cannot be accepted for QoS booking by the operator, for example because it is outside the supported coverage, then the server will return an error with `422 QOS_BOOKING.INVALID_AREA` error code. |
There was a problem hiding this comment.
We have curently 3 errors for areas:
- QOS_BOOKING.NOT_MANAGED_AREA_TYPE -> If the area type is not supported
- QOS_BOOKING.AREA_NOT_COVERED -> The service cannot be provided in the requested area
- QOS_BOOKING.INVALID_AREA -> Syntactically correct but cannot be accepted, for example because the requested area is too small to be supported by the system.
There was a problem hiding this comment.
I added text for missing area errors.
|
@Masa8106 please let me know when I can re-review again, thanks |
|
@jlurien, I will check the comments this afternoon. Thank you for reminding me. |
Co-authored-by: Jose Luis Urien <jlurien@gmail.com>
|
@jlurien, would you review this PR again? Thank you. |
3 participants
What type of PR is this?
What this PR does / why we need it:
To clarify the conditions that might lead to the some error codes being returned by the API.
Which issue(s) this PR fixes:
Fixes #125
Special notes for reviewers:
None
Changelog input
Additional documentation
None