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

In T85762#3294113, @Ciencia_Al_Poder wrote:

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

In T85762#3447735, @Seb35 wrote:

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 task, 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.

One example would be with Cargo; runJobs.php would show "uncommited DB writes", which is true - but it's because there was a previous exception, such as:
Error 1213 from CargoBackLinks::removeBackLinks, Deadlock found when trying to get lock; try restarting transaction.