Uninett / Argus

Argus is an alert aggregator for monitoring systems
GNU General Public License v3.0
18 stars 13 forks source link

Uniform error cause response #304

Open podliashanyk opened 3 years ago

podliashanyk commented 3 years ago

Actual behaviour Different endpoints return error cause in different formats.

Example 1:

Screenshot 2021-07-01 at 09 49 46

Example 2:

Screenshot 2021-07-01 at 09 55 21

Example3:

Screenshot 2021-07-01 at 09 57 46

Example4:

Screenshot 2021-07-01 at 09 59 42

Wanted behaviour Uniform error format, for example: { "error_message": "Error cause(s) message" }

hmpf commented 3 years ago

Example 1 and 4 are of the same type: the errors are validation errors for a specific field in the previously posted data. If the same field names are used in the frontend, this makes it possible to connect a specific validation error to a specific field.

Example 3 is default for all 404 replies, so you can safely take whatever text is pointed to by the "detail"-key.

Example 2 is a bit of a mystery, will need research.

There's at least one type missing: you can get a key "non-field-errors" or something like that that is a validation error if there is a relationship between multiple fields. for instance: if you choose X for field A you may not fill anything into field B. This error might also be used for database problems like integrity errors IIRC (integrity errors: most likely caused by multiple fields (columns) being UNIQUE as a set together, which cannot be caught until saving to the database since the values are checked against all existing values of the same type at that point.)

hmpf commented 3 years ago

Turns out changing how this works is tricky because as is, ValidationErrors are raised more places than just the validation methods. We'd probably need to clean that up first.

However, taking into account the status code in addition to the json-blob should help matters. Validation-errors should only happen with a 400-status code, and should always have a key-value structure.

hmpf commented 1 year ago

How to write your own exception handler, to control the format of the error-jsonblob.

https://rednafi.github.io/reflections/uniform-error-response-in-django-rest-framework.html

hmpf commented 1 year ago

Plenty of existing libraries, like this one:

https://github.com/ghazi-git/drf-standardized-errors

drf-problems supports https://www.rfc-editor.org/rfc/rfc7807

hmpf commented 1 year ago

Once again, highlighting https://www.rfc-editor.org/rfc/rfc7807

Example:

{
    "status": 400,
    "type": "https://example.com/probs/out-of-credit",
    "title": "You do not have enough credit.",
    "detail": "Your current balance is 30, but that costs 50.",
    "instance": "/account/12345/msgs/abc",
    "balance": 30,
    "accounts": ["/account/12345",
                 "/account/67890"]
}

"status", "type", "title", "detail" and "instance" are described in RFC 7807, but as you can see other fields may be added, in this case "balance" and "accounts". The latter two may to be described in the page linked to by "type".