Checklist
Steps to reproduce
Hi,
I'm a newcomer to DRF, and an issue I'm having is that I'm using Django's UUIDField in some models and using them as the lookup_fields in my serializers. They work fine when I send a request with a correctly-formatted UUID, but DRF simply fails with a server error if the request sends an invalid string (such as "invalid") - instead of responding with HTTP 400 or 404, which was what I would expect. I tried debugging the code a bit, and it doesn't seem to be validated anywhere when calling retrieve() from the RetrieveModelMixin. Then I receive a django.core.exceptions.ValidationError which is bubbled up until the application layer, instead of being handled by DRF gracefully, since it's a case of user error and not application error.
I believe this is a bug, but, if it's not and if it's up to the developers to code the validation themselves, please let me know.
So the steps to reproduce are pretty simple:
- Add a UUIDField to a model
- Define a serializer for this model
- Define the uuid field as the lookup field
- Send a test request to the detail view but passing "invalid" as the uuid
Expected behavior
Either an HTTP 400 or 404 response
Actual behavior
The application fails and lets the low-level validation error bubble up, responding with an HTTP 500 response to the client
Checklist
masterbranch of Django REST framework.Steps to reproduce
Hi,
I'm a newcomer to DRF, and an issue I'm having is that I'm using Django's
UUIDFieldin some models and using them as thelookup_fields in my serializers. They work fine when I send a request with a correctly-formatted UUID, but DRF simply fails with a server error if the request sends an invalid string (such as "invalid") - instead of responding with HTTP 400 or 404, which was what I would expect. I tried debugging the code a bit, and it doesn't seem to be validated anywhere when callingretrieve()from theRetrieveModelMixin. Then I receive adjango.core.exceptions.ValidationErrorwhich is bubbled up until the application layer, instead of being handled by DRF gracefully, since it's a case of user error and not application error.I believe this is a bug, but, if it's not and if it's up to the developers to code the validation themselves, please let me know.
So the steps to reproduce are pretty simple:
Expected behavior
Either an HTTP 400 or 404 response
Actual behavior
The application fails and lets the low-level validation error bubble up, responding with an HTTP 500 response to the client