[BUG] Exception handler doesn't rollback transaction of non-default connection

[aradbar]

Checklist

• [X] I have verified that that issue exists against the master branch of Django REST framework.
• [X] I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• [X] This is not a usage question. (Those should be directed to the discussion group instead.)
• [X] 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.)
• [X] 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

1. Have a project with two db connections setup with ATOMIC_REQUESTS = True
2. Have a view that makes a change in the non-default connection and then raises some APIException (I tested with ValidationError)
3. Check to see if the change was committed

Expected behavior

The transaction should not be committed

Actual behavior

The transaction is committed

What I saw in the code

1. exception_handler is using the function set_rollback() - https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L98
2. set_rollback only takes the default connection into account https://github.com/encode/django-rest-framework/blob/master/rest_framework/views.py#L65

def set_rollback():
    atomic_requests = connection.settings_dict.get('ATOMIC_REQUESTS', False)
    if atomic_requests and connection.in_atomic_block:
        transaction.set_rollback(True)

[xordoquy]

Seems correct to me. Want to submit a PR about it ?

[aradbar]

Sure, thanks

[aradbar]

@xordoquy Am I supposed to assign the PR to someone or do anything else?

[xordoquy]

@aradbar saw your PR, looks good at first, need to throw some more though about possible side effects

[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.

[philipstarkey]

This looks like it was fixed in #7739

[auvipy]

thanks for verifying