Page MenuHomePhabricator

Get rid of the Uncommitted DB writes notice
Closed, DeclinedPublic

Description

Mediawiki throws this notice whenever there isn't a matching commit/rollback instruction after a begin transaction has been issued.

To my understanding, this notice should be for developers only, and should never hit production users. However, this is not the case.

The problem with this notice is that it often pops when there's another PHP exception, that is thrown, leaving an unclosed transaction, and this notice hides the real exception, making debugging more hard. For whatever reason, many users hitting this situation only get the Uncommitted DB writes error. See also T58269, T67205, T85734, T69842, where you can find examples where the real error message is completely hidden. This makes very difficult for anyone trying to help those users.

My proposal is:

  • Don't throw this notice unless $wgDevelopmentWarnings is set to true.
  • Don't throw this notice if there has been a previous exception, to prevent hiding the real one. Maybe error_get_last() could be used for this purpose?

Event Timeline

Ciencia_Al_Poder raised the priority of this task from to Needs Triage.
Ciencia_Al_Poder updated the task description. (Show Details)
Ciencia_Al_Poder awarded a token.
Ciencia_Al_Poder added a subscriber: Ciencia_Al_Poder.

I do think this warning is useful in production - it's an indication of data loss, and should be tracked. If it happens without being provoked by a prior error, it means something isn't handling transactions right.

However, it should not mask any original errors, of course. I'm not sure how to best achieve this, though. Does error_get_last work at all for exceptions?

Still current in MediaWiki 1.27: Topic:Tr7p9m3hybmc7kf3

As I understand the original description, this task is not about the issues themselves (which are described in specific tasks) but about how the issues are handled (which debug log? which error level? etc).

A similar task is T55341 "Convert $wgDebugDBTransactions to debug log group."

As I understand the original description, this task is not about the issues themselves (which are described in specific tasks) but about how the issues are handled

The task is to avoid throwing this error when it's masking the original error (usually a Fatal exception). In some setups (still I don't know how this happens, maybe when php is run as CGI script?) the user is presented only with the last error thrown by PHP, and all previous errors are vanished, leaving this useless warning with no way to know the original exception to track it.

Another example of how bad is this behavior: Topic:U6assggpblncfyf2 This happens during the installer

The problem of "Uncommitted DB writes" is a class of errors, not an individual error by itself. Comparable to e.g. "Undefined variable" or "Undefined index". Removing the detection and error for that is unlikely given that code triggering the error is incorrect, and should be detected and reported.

I would suggest declining this issue, however, I see one thing in particular that may be useful as its own task, and/or we can repurpose this task for that:

Task description:

Don't throw this notice if there has been a previous exception, to prevent hiding the real one.

Can you show explain when "Uncommitted DB writes" would be shown, and another php error is suppressed? It is unclear to me how or why that would happen. And if it does, I agree that is bad and we should fix that.

Krinkle changed the task status from Open to Stalled.Jul 23 2019, 4:15 PM