set_rollback's atomic check is inaccurate

[adamchainz]

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

Wrap a view that errors with @non_atomic_requests, but use a transaction around it somehow. The easiest way is to test it from a Django TestCase, which uses transactions around each test. Another way would be to have a custom middleware that does a transaction a different way.

Expected behavior

rest_framework.set_rollback should not call transaction.set_rollback because the view is declared as non-atomic.

Actual behavior

rest_framework.set_rollback calls transaction.set_rollback. Its check for "is this view non-atomic" checks connection.in_atomic_block which as indicated above can be true for a number of reasons.

[sww314]

I am seeing this on DRF 3.12

When using a @transaction.non_atomic_requests, I get an transaction error. I am also using a multi-db solution.

[stale]

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]

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.