encode
Preserve exception messages for wrapped Django exceptions
I did not review your contributing guidelines, nor did I test anything using the automated tests. I also did only the most minimal of non-automated testing. Still, I thought I'd leave this here, as it may be useful to others. See it as an "issue description with PoC of a solution" if you will.
The problem: when raising standard Django exceptions Http404 or PermissionDenied, the error messages of these exceptions do not show up in the DRF's response. This is because these exceptions are recreated in the piece of code that this PR adapts.
In this PR this is solved by making sure the recreated exceptions are recreated with the same arguments as the original versions. Whether the signatures actually match up, I did not check properly.
It looks like there's a test case that'd need updating...
_ TestFilterBackendAppliedToViews.test_get_instance_view_filters_out_name_with_filter_backend _
tests/test_generics.py:522: in test_get_instance_view_filters_out_name_with_filter_backend
assert response.data == {'detail': 'Not found.'}
E AssertionError: assert {'detail': Er...='not_found')} == {'detail': 'Not found.'}
E Differing items:
E {'detail': ErrorDetail(string='No BasicModel matches the given query.', code='not_found')} != {'detail': 'Not found.'}
E Use -v to get the full diff
It looks like there's a test case that'd need updating...
Indeed, but what would the desired behavior be? If I understand it correctly that test shows that the response data of a request contains some Python objects (as opposed to pure json)... perhaps because of mocking at some level?
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.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Reading the discussion above it appears to me that the staleness is caused by a lack of response from @tomchristie on my question on how to proceed.
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.
I've updated the failing test to be succeeding; this at least amounts to having an implicit test on the newly introduced behavior as more or less suggested by @jeking3
If I understand it correctly that test shows that the response data of a request contains some Python objects (as opposed to pure json)... perhaps because of mocking at some level?
As I understand now: no. ErrorDetail are picked up by another part of the DRF machinery before an actual HTTP response is sent over the wire. So having a test match on ErrorDetail is fine.
Stalebot go away
On Mon, Apr 18, 2022, 13:57 stale[bot] @.***> wrote:
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.
— Reply to this email directly, view it on GitHub https://github.com/encode/django-rest-framework/pull/8051#issuecomment-1101387267, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWUWOQAB7JV37M4CDRPBLVFVL3BANCNFSM47FHYKKQ . You are receiving this because you authored the thread.[image: Web Bug from https://github.com/notifications/beacon/AABWUWKBJDCZGACBCAL63WDVFVL3BA5CNFSM47FHYKK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIGS5MAY.gif]Message ID: @.> [ { @.": "http://schema.org", @.": "EmailMessage", "potentialAction": { @.": "ViewAction", "target": " https://github.com/encode/django-rest-framework/pull/8051#issuecomment-1101387267", "url": " https://github.com/encode/django-rest-framework/pull/8051#issuecomment-1101387267", "name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { @.***": "Organization", "name": "GitHub", "url": " https://github.com" } } ]