ValidationError doesn't preserve JSON field's types

[Genarito]

Checklist

• I have verified that that issue exists against the master branch of Django REST framework.
• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• This is not a usage question. (Those should be directed to the discussion group instead.)
• This cannot be dealt with as a third party library. (We prefer new functionality to be in the form of third party libraries where possible.)
• I have reduced the issue to the simplest possible case.
• I have included a failing test as a pull request. (If you are unable to do so we can still accept the issue.)

Steps to reproduce

I have a Response object with some Enums which I use in the frontend to identify some specific issues. I'm returning that response raising a ValidationError:

from enum import Enum

class ResponseCode(Enum):
    SUCCESS = 1
    ERROR = 2

class MyErrorCode(Enum):
    INVALID_FORMAT_NON_NUMERIC = 1
    OTHER = 2


class ResponseStatus:
    def __init__(self, code: Enum, message: str = '', internal_code: Enum = None):
        self.code = code.value
        self.message = message
        self.internal_code = internal_code.value if internal_code is not None else None

    def to_json(self):
        return self.__dict__

class MySerializer(serializers.ModelSerializer):
    class Meta:
        model = MyModel
        fields = '__all__'

    @staticmethod
    def validate_name(value: str):
        raise serializers.ValidationError({
	    'status': ResponseStatus(
		ResponseCode.ERROR,
			message='Invalid string',
			internal_code=MyErrorCode.INVALID_FORMAT_NON_NUMERIC
	    ).to_json(),
	})

The problem is that, in this case, the fields code and internal_code are integer, but when they are returned they're implicitly casted to string for some reason:

I have some views which has the same response but they're returned using JsonResponse in views.py:

JsonResponse({...}, safe=False)

The result:

And this works correctly, so I think it's a problem with the serialization applied in the ValidationError returning.

Expected behavior

Preserve the primitives types of information in the returned JSON object as shown in the above img (with JsonResponse)

[wjiuhe]

django-rest-framework/rest_framework/exceptions.py

Line 39 in bb13352

text = force_str(data)

https://github.com/django/django/blob/48b4bae983a1f9a73624fe62ef5bd1130b0dba39/django/utils/encoding.py#L48

I think the related code is here. Should or not handle the integer case before calling force_str?

[j-boivie]

I have a similar issue when raising an exception from a custom permissions class, where bools are not serialised to JSON correctly. I.e. this:

[...]
raise PermissionDenied({"Error": True, "Access": False})

Results in

{
    "Error": "True", 
    "Access": "False"
}

So I assume that the exception needs to handle bools as well before coercing into strings as @wjiuhe pointed out

[Genarito]

Is there any repo mantainer here to make a PR? In the case is not, could I make a PR in my free time, or is expected to be forced to string always?

[ChrisCrossCrash]

I too think it would be nice to preserve the primitive types of data sent back with the error information.

However, I don't think it would be a good idea to change the default behavior. Consider this line in the official docs:

.detail - Return the textual description of the error.

Emphasis on the word "textual".

Also, this behavior is baked into so many existing applications already. Changing it would break a lot of stuff.

Maybe a special parameter could be added to the exception classes, like json_parse_detail:

raise PermissionDenied({"Error": True, "Access": False})

results in

{
    "Error": "True", 
    "Access": "False"
}

but

raise PermissionDenied({"Error": True, "Access": False}, json_parse_detail=True)

results in

{
    "Error": true, 
    "Access": false
}

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[auvipy]

Hello, can you please atleast contribute the failing test case for this issue?

[tomchristie]

However, I don't think it would be a good idea to change the default behavior. Consider this line in the official docs:

.detail - Return the textual description of the error.

Emphasis on the word "textual".

This looks like the correct take to me.

[Genarito]

Yep, an optional parameter as @ChrisCrossCrash proposed would be nice!

[FelipeFranke5]

I just opened an discussion for this problem and then found this Issue.. welp.
#9252

I agree, an optional parameter would be really useful in this case!