For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
The Special Page is supposed to write a record to a shared external database and then use the autoincremented row number to set the name of the page that will be created. I’m using $dbw->insert to do this. In 1.31 the autoincrement index gets bumped but the row doesn’t get written. If I do the same insert from a maintenance script, it works, so I’m assuming it doesn’t have anything to do with general configurations or other extensions (which I’ve inactivated).
After it gets a value for the lastInsertID it tries to make a page from a template. That page is never created and I see this in the error logs:
PHP Fatal error: Uncaught Wikimedia\Rdbms\DBUnexpectedError: Wikimedia\Rdbms\Database::close: mass commit/rollback of peer transaction required (DBO_TRX set). in /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php:916\nStack trace:\n#0 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1217): Wikimedia\Rdbms\Database->close()\n#1 [internal function]: Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\DatabaseMysqli))\n#2 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1640): call_user_func_array(Object(Closure), Array)\n#3 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1218): Wikimedia\Rdbms\LoadBalancer->forEachOpenConnection(Object(Closure))\n#4 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1208): Wikimedia\Rdbms\LoadBalancer->closeAll()\n#5 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBal in /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php on line 916, referer: http://localhost/omp/wiki/index.php/Special:StrainNewPage
This happens even if comment out the code that accesses the external database completely and hard code the ID.
Other Special Page extensions we have that create new pages seem to work on 1.31.1. I’m wondering if this is related to the method that now fails being a callback from HTMLforms for processing form submission.
Any insight, help in debugging this would be much appreciated. Apologies if I’m using some terminology incorrectly (I’m a biologist more than a coder).
Jim Hu
That means an implicit transaction [1] was started but not committed/cancelled. For special pages transaction handling is done by the framework and this should not happen unless you are doing something strange, like obtaining a connection in a non-standard way. Application errors (ie. something throwing a non-database-related exception) sometimes bring the database abstraction layer into an inconsistent state, so maybe this is a secondary error caused by something else - check your exception logs.
[1] https://www.mediawiki.org/wiki/Database_transactions#Transaction_scope
On Mon, Apr 22, 2019 at 9:31 AM Jim Hu jim.hu.biobio@gmail.com wrote:
For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
The Special Page is supposed to write a record to a shared external database and then use the autoincremented row number to set the name of the page that will be created. I’m using $dbw->insert to do this. In 1.31 the autoincrement index gets bumped but the row doesn’t get written. If I do the same insert from a maintenance script, it works, so I’m assuming it doesn’t have anything to do with general configurations or other extensions (which I’ve inactivated).
After it gets a value for the lastInsertID it tries to make a page from a template. That page is never created and I see this in the error logs:
PHP Fatal error: Uncaught Wikimedia\Rdbms\DBUnexpectedError: Wikimedia\Rdbms\Database::close: mass commit/rollback of peer transaction required (DBO_TRX set). in /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php:916\nStack trace:\n#0 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1217):
Wikimedia\Rdbms\Database->close()\n#1 [internal function]: Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\DatabaseMysqli))\n#2 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1640):
call_user_func_array(Object(Closure), Array)\n#3 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1218):
Wikimedia\Rdbms\LoadBalancer->forEachOpenConnection(Object(Closure))\n#4 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1208):
Wikimedia\Rdbms\LoadBalancer->closeAll()\n#5 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBal in /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php on line 916, referer: http://localhost/omp/wiki/index.php/Special:StrainNewPage
This happens even if comment out the code that accesses the external database completely and hard code the ID.
Other Special Page extensions we have that create new pages seem to work on 1.31.1. I’m wondering if this is related to the method that now fails being a callback from HTMLforms for processing form submission.
Any insight, help in debugging this would be much appreciated. Apologies if I’m using some terminology incorrectly (I’m a biologist more than a coder).
Jim Hu _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
I am not familiar with Special:StrainNewPage, I am guessing that is custom code not available from a standard extension? If it is not private and you could share that custom code (or at least part of it) maybe someone can help you better to see what is the problem in your case. :-)
It’s a custom extension used by my lab only, and while a version is on our public github, it’s going to be hard to follow because of entanglement with some other custom code libraries we use that wrap the WikiPage class to accommodate our use of the TableEdit extension. If you want to look anyway, it’s here:
https://github.com/microbialphenotypes/OMPwiki/blob/master/OMP/specialpages/...
But it would probably be more useful for you to wait until I can pare it down to something that is minimal to see if I can isolate the problematic part and then push that to github.
I was hoping someone had seen a similar problem with Special page development and had a simpler answer!
Thanks!
Jim
On Apr 23, 2019, at 10:29 AM, Jaime Crespo jcrespo@wikimedia.org wrote:
For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
I am not familiar with Special:StrainNewPage, I am guessing that is custom code not available from a standard extension? If it is not private and you could share that custom code (or at least part of it) maybe someone can help you better to see what is the problem in your case. :-)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
$dbw = wfGetDB( DB_SLAVE ); $dbw->insert( 'omp_master.strain', array( 'id' => null, 'name' =>
$formData['strain_name_field'] ) );
You should use wfGetDB( DB_MASTER ) to get a DB handle for writing.
On Tue, Apr 23, 2019 at 9:16 AM Jim Hu jim.hu.biobio@gmail.com wrote:
It’s a custom extension used by my lab only, and while a version is on our public github, it’s going to be hard to follow because of entanglement with some other custom code libraries we use that wrap the WikiPage class to accommodate our use of the TableEdit extension. If you want to look anyway, it’s here:
https://github.com/microbialphenotypes/OMPwiki/blob/master/OMP/specialpages/...
But it would probably be more useful for you to wait until I can pare it down to something that is minimal to see if I can isolate the problematic part and then push that to github.
I was hoping someone had seen a similar problem with Special page development and had a simpler answer!
Thanks!
Jim
On Apr 23, 2019, at 10:29 AM, Jaime Crespo jcrespo@wikimedia.org
wrote:
For one of our custom wikis we have a Special Page that creates new
pages
based on form input. This used to work in MW1.23 but in the long
overdue
update to MW1.31 it stopped working.
I am not familiar with Special:StrainNewPage, I am guessing that is custom code not available from a standard extension? If it is not private and you could share that custom code (or at least part of it) maybe someone can help you better to see what is the problem in your case. :-)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Following up.
I did some tests on some Special Page extensions I wrote based on the updated documentation at mediawiki.org http://mediawiki.org/. Here they are, in case anyone is interested. Both work, so the HTMLform callback is NOT the problem.
https://github.com/jimhu-tamu/scratch/tree/master/SpecialPageTests https://github.com/jimhu-tamu/scratch/tree/master/SpecialPageTests
Since then, I have a new hypothesis about what is happening and am wondering if someone here can clarify if this is correct or not.
The code is throwing the mass commit error only if something interrupts processing before execution is complete - that includes my testing with die() statements or other errors that I’ve been tracking down. So it seems like doing execution via the Special page is caching all database interactions into some unknown number of transactions that never get committed until page execution makes it all the way to the end. If it doesn’t, the mass commit error happens.
It looks to me like in the earlier versions of MW creating a page is committed during execution, so one can pull a revision for that page and do stuff to it in the same pass through the special page execution. Now it’s acting like there is not revision to pull after doing WikiPage::doEditContent(). When I comment out the right blocks of code, I can see that I create the desired page from my template, but my attempt to pull the revision text back out and do something to it blanks the page and causes errors from code that expects there to be text in the revision.
I think I can find the problems now or do a different kind of workaround. But I’m curious if I’m right about the transactions and uncommitted page creation.
Thanks
Jim
On Apr 23, 2019, at 11:15 AM, Jim Hu jim.hu.biobio@gmail.com wrote:
It’s a custom extension used by my lab only, and while a version is on our public github, it’s going to be hard to follow because of entanglement with some other custom code libraries we use that wrap the WikiPage class to accommodate our use of the TableEdit extension. If you want to look anyway, it’s here:
https://github.com/microbialphenotypes/OMPwiki/blob/master/OMP/specialpages/...
But it would probably be more useful for you to wait until I can pare it down to something that is minimal to see if I can isolate the problematic part and then push that to github.
I was hoping someone had seen a similar problem with Special page development and had a simpler answer!
Thanks!
Jim
On Apr 23, 2019, at 10:29 AM, Jaime Crespo jcrespo@wikimedia.org wrote:
For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
I am not familiar with Special:StrainNewPage, I am guessing that is custom code not available from a standard extension? If it is not private and you could share that custom code (or at least part of it) maybe someone can help you better to see what is the problem in your case. :-)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 26, 2019 at 10:19 AM Jim Hu jim.hu.biobio@gmail.com wrote:
The code is throwing the mass commit error only if something interrupts processing before execution is complete - that includes my testing with die() statements or other errors that I’ve been tracking down. So it seems like doing execution via the Special page is caching all database interactions into some unknown number of transactions that never get committed until page execution makes it all the way to the end. If it doesn’t, the mass commit error happens.
MediaWiki generally wraps database requests in an automatic transaction (at least when you are in a web request - jobs and maintenance scripts have somewhat different rules). There are ways to push callbacks into a followup transaction too, with things like DeferredUpdate or Database::onTransactionCommitOrIdle. There shouldn't really be a way for a special page to cause errors with that, other than manually calling commit/rollback methods in the wrong way. die() would prevent the transaction from being committed but wouldn't generate an error, I think.
It looks to me like in the earlier versions of MW creating a page is committed during execution, so one can pull a revision for that page and do stuff to it in the same pass through the special page execution. Now it’s acting like there is not revision to pull after doing WikiPage::doEditContent(). When I comment out the right blocks of code, I can see that I create the desired page from my template, but my attempt to pull the revision text back out and do something to it blanks the page and causes errors from code that expects there to be text in the revision.
That sounds like consistent read [1] issues - MySQL transactions don't see rows that have been newly inserted (in the same transaction) under certain circumstances. The usual workaround for that is to do a locking read, e.g. use the 'LOCK IN SHARE MODE' option with Database::select.
[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html
wikitech-l@lists.wikimedia.org