Classify validation errors

[qsorix]

I'm using REST framework to implement an API that's very verbose about errors in the request. One thing I cannot do right at this moment is reporting the type of a validation error. I need this type because automatically generated bindings make good use of it.

For example, when field is required, I need not only to say which field it is, but also add error code "missing". Other error codes include "blank", "incorrect_value" and so on.

I'm aiming for things like this in my error response:

{
  "field": "/customer/address/city",
  "code": "blank",
  "details": "The attribute '/customer/address/city' can't be blank (neither null nor empty)."
}

Right now serializers.ValidationError gives me everything I need, except the code. The type of a problem that a validator/field recognized is lost. We'll technically, it is described in the message carried by the exception, but that's not intended for such use.

By reading the source code, I've found method Field.fail(self, key, **kwargs). The key is kinda what would do the trick for me if only it was available somewhere in the exception.

Any hints how I can solve my problem? Maybe it makes sense to turn this into an enhancement?

Right now I can monkey patch the Field.fail, add the key into exceptions and map known keys into my codes in an exception handler, but that's obviously an abuse of private implementation and will likely break when implementation changes.

[tomchristie]

It's feasible that we'd accept a pull request that included the 'code' information in the validation error so that just a custom exception handler would be sufficient (I don't know how easy it'd be to add in the 'code' information to the exception to)

Might be worth sharing what you're doing at the moment to get a better idea of what that change might look like.

[qsorix]

Initially I thought about monkey patching Field.fail. That itself was easy, but I quickly realized the information is lost anyway, when errors are being gathered by the serializers (in the summarized ValidationError we have only messages from individual exceptions).

Instead, I've bypassed the issue by prepending the key to the error messages of fields and validators. That's hackish but stays within the public API. One problem I still have is dealing with errors I don't understand in my code, e.g. validations performed by Django Models. Perhaps I'll just use some generic "unknown" code for those.

Now, I still think that adding dedicated 'code' to validation errors is a better way to go, so if you'll be happy to see a pull request, I may prepare one. After all, I'm not happy with running my hackish workarounds on production. ;)

However, at this point, a suggestion how the summarized exception should look like is welcomed. By summarized, I mean the code in this area: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/serializers.py#L270

Some ideas of myself...

I could just change each error string to a tuple (code, message) but this isn't backward compatible...
I could make this controllable by a configuration option... (e.g. REST_FRAMEWORK.INCLUDE_ERROR_CODES)
Or I could add some sort of a builder hook method that users can use. It would take an exception and return a value that'll be included in the summarized error tree. By default it would just use strings, and a custom version could gather both strings and codes.
Or I could change existing strings into some objects that behave like strings, but also include code property.

I think I prefer the idea with a customizable builder function. Your thoughts?

[qsorix]

Hi again, I've been working on this and I'm rather content with the results. There weren't so many changes in the REST framework, and the code of my use case got considerably simpler when I switched to the forked version.

Here's the pull request, I'll be happy to hear your comments:
#3137

I hope the commit message describes the whole solution clearly.

On another branch I've made sure everything works as intended. I'm not convinced this should be pulled in as well, so I kept it separate.
I did the check by customizing errors to be tuples of (message, error_code) and updating all REST tests to expect errors in such form. Time consuming but easy change. Those changes are here, in case you're interested how I check that the pull request is covering all errors:

qsorix/django-rest-framework@error-codes-enhancement...qsorix:error-codes-enhancement-self-check-all-errors

[qsorix]

Updated pull request: #3169

[tomchristie]

Error codes now included in the upcoming 3.5 release.

[qsorix]

👍 ❤️