Code

Opened 4 years ago

Closed 4 years ago

#13265 closed (duplicate)

TransactionManagementError doesn't allow for easy debugging of views

Reported by: orokusaki Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Keywords: transaction
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

When using @transaction.commit_manually on a view, if an exception is not caught in the view, and thus transaction.rollback() is not used, TransactionManagementError() is raised. When this happens, the stack trace is very bare and it is nearly impossible to figure out what happened without removing manual transaction management from that view.

Attachments (0)

Change History (3)

comment:1 Changed 4 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

I don't know if I'm seeing the same problem (it's difficult to know for certain without test code to demonstrate your problem), but based on your explanation, I see a TransactionManagementError that reports that "Transaction managed block ended with pending COMMIT/ROLLBACK". I'm not entirely sure what extra information we can provide in this circumstance -- the error is telling you exactly what has gone wrong. It's not like we're rethrowing an error and thereby hiding a stack trace. The problem is that there is a code path in your view which has either not thrown errors, or caught all errors that have been thrown, but that allows a clean return from the view with pending transaction activity. The request URL, GET/POST and cookie values are all shown on the debug page, which should be enough to reproduce the bad request and determine how the code path is returning with this pending state.

Given that this report doesn't give a specific course of action, and the desired course of action isn't obvious (to me, anyway), I'm closing wontfix.

comment:2 Changed 4 years ago by John Obelenus

  • Keywords transaction added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Seeing TransactionManagementError? that reports that "Transaction managed block ended with pending COMMIT/ROLLBACK" is the correct symptom.

If you don't commit() or rollback() you will get this error. That much is obvious and correct. The problem that 'orokusaki' is talking about is if the view (or code called within the view) doesn't catch an exception thrown, the view will still give you TransactionManagementError. So, yes you doing just this: "It's not like we're rethrowing an error and thereby hiding a stack trace." The return of the view function is an exception, db.transaction sees the failure case, and raises its own TME exception - hiding the true problem. The true exception can be an ImportError, ValueError, TypeError, or any basic error that fingers angry at their master can cause. In my case I had a simple ValueError from mistyping a variable name, thus giving an undeclared variable.

The reproduction steps ought to be pretty simple. Cause a basic exception in a view with the @transaction.commit_manually decorator, don't catch it, and see the TME exception, not the basic exception with a trace to find it. If I can do anything to get a test case to let me know how best to submit it.

comment:3 Changed 4 years ago by guettli

  • Resolution set to duplicate
  • Status changed from reopened to closed

I guess it is a duplicate for #6623

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.