Having an error raised during a transaction-decorated view will drop the error on the floor

[jstpierre@…]

Consider:

@commit_manually
def my_view():
    transaction.set_dirty() # or a DB call or something
    raise Exception("asdf")

As the transaction is dirty, when exiting the decorator, it will raise an exception because the transaction is dirty. Duh. Instead, if there is an exc_value set in the exiting function, Django should re-raise it immediately and not drop my exception on the floor.

[Aymeric Augustin]

Here's the same problem shown in a shell:

>>> from django.db import transaction 
>>> with transaction.commit_manually():
...     transaction.set_dirty()
...     raise ValueError('doh!')
... 
Traceback (most recent call last):
  File "<console>", line 3, in <module>
  File "/Users/myk/Documents/dev/django-trunk/django/db/transaction.py", line 202, in __exit__
    self.exiting(exc_value, self.using)
  File "/Users/myk/Documents/dev/django-trunk/django/db/transaction.py", line 287, in exiting
    leave_transaction_management(using=using)
  File "/Users/myk/Documents/dev/django-trunk/django/db/transaction.py", line 51, in leave_transaction_management
    connection.leave_transaction_management()
  File "/Users/myk/Documents/dev/django-trunk/django/db/backends/__init__.py", line 123, in leave_transaction_management
    "Transaction managed block ended with pending COMMIT/ROLLBACK")
TransactionManagementError: Transaction managed block ended with pending COMMIT/ROLLBACK

At first sight, it would be more logical (and easier to debug) if the original exception wasn't swallowed. I'd like if someone familiar with transaction management could confirm.

[Anssi Kääriäinen]

The way commit_manually works is that you must either commit or rollback the transaction. This is explicitly ​documented. So, the given TransactionManagementError is more like a hint saying that you are using the commit_manually decorator improperly.

I don't think this should be changed in a way where the original exception is risen and no hint is given. This could be a source of transaction leak. There might be some point of changing the decorator to do automatic rollback on exceptions. This would be a change from currently documented behavior.

As currently documented, the reported problem is an user error. If the currently documented behavior should be changed needs a design decision.

[jstpierre@…]

Since I filed this bug, I found a duplicate somewhere with a patch. I cannot find it again for the life of me, sorry.

[jstpierre@…]

Duplicate of #6623