[00:04:11] Looks like mediawik-core tests are failing due to a PHPUnit deprecation being violated in Wikibase [00:04:19] not sure how this slipped into master? [00:04:31] 02:56:10 2) Wikibase\Client\Tests\ClientParserOutputDataUpdaterTest::testUpdateItemIdProperty [00:04:31] 02:56:10 The optional $checkForObjectIdentity parameter of assertContains() is deprecated and will be removed in PHPUnit 9. Refactor your test to use assertContainsEquals() instead. [00:06:15] https://github.com/wikimedia/mediawiki-extensions-Wikibase/search?q=assertContains&unscoped_q=assertContains [00:06:17] Quite a few of them [00:07:56] Krinkle: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/566327/ [00:08:03] Looks like that patch didn't quite fix everything it should've [00:08:33] Oh [00:08:34] >This should fix all remaining warnings but one, where PHPUnit suggests [00:08:35] using assertContainsEquals, which was introduced in PHPUnit 8, hence we [00:08:35] cannot fix it before upgrading. [00:08:36] how did the failure get into master though? [00:08:52] Eitiher they were added without failing CI, or phpunit was upgraded without testing CI. [00:08:58] neither seems likely [00:09:23] We couldn't switch assertContains to assertContainsEquals until we'd upgraded to 8... [00:09:54] But no one made the patch as a followup... [00:12:17] Reedy: yeah, but was phpunit somehow silently upgraded and/or upgraded in a way that CI didn't run Wikibase tests? [00:12:28] the warnings are fatal in our config right? [00:12:31] it's failing the build for me [00:12:32] oh wait [00:21:28] I guess it was fixed ~20h ago [00:21:28] https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/559321/ [00:21:29] must've been a fluke? still strange that that was even possible [12:30:36] Hello everyone [12:31:04] https://paste.touhou.fm/iposazufoj.txt I am getting this error after having updated to thew nest stable release. [12:31:15] Did I perform the update wrong or something? [15:46:10] So, I have a DataUpdate, and I want to be able to commit multiple transactions within it... Anyone got any pointers... [15:46:31] Right now I'm looking at and playing with TransactionRoundAwareUpdate [15:49:42] * addshore re reads https://www.mediawiki.org/wiki/Database_transactions#Splitting_writes_into_multiple_transactions [16:00:39] Krinkle: ^^ any ideas? [16:02:21] perhaps beginMasterChanges is actually what I want, rather than startAtomic [16:04:14] addshore: Yeah, if you explicitly need to commit in-between you'll probably want to go with TransactionRoundDefiningUpdate and do your own begin/commit. [16:04:33] let me give that a shot [16:04:37] addshore: However if you don't need to own the transaction and merely want to commit and re-start mid-way a few times you don't need to own it [16:04:51] addshore: This is what commitAndWaitForReplication() is for [16:04:56] and you shuld have a Ticket alreayd to use with it [16:05:06] hmmmm [16:05:19] that way core keeps owning the tx and ensures begin/commit at the start/end but allows you do commit progress mid-way [16:05:21] I dont need to own it, just mutliple times through the update I want to commit and start a new transaction [16:05:39] which should cover most use cases unless you e.g. explicitly are calling code like nested actual Deferredupdate or Job classes that own their own transaction [16:05:49] yeah then commitAndWaitForReplication() should be what you need I think [16:05:56] *facepalm* [16:06:02] let me give it a go :P [16:06:26] addshore: example [16:06:27] https://gerrit.wikimedia.org/g/mediawiki/core/+/a04633f678fb23d6066b95ec66621bc8a3624dce/includes/deferred/LinksDeletionUpdate.php#112 [16:06:35] This is a DataUpdate that commits batches mid-way [16:06:49] same for CategoryMembershipChangeJob [16:07:18] it is unusual in a Deferred update because doing work that is too big to do in one batch usually suggests it is also undesirable to run on the web server in a way that has no retry or other recovery and holding up resources there [16:07:26] but shoudl work fine none theless , same principle [16:07:58] right, so the caller of commitAndWaitForReplication needs access to the transaction ticket [16:08:19] Yep, every job and data update has that [16:08:26] ack [16:09:18] also, it looks like releaseConnection is just no longer needed? [16:13:14] bah, im sure the data update has the transaction ticket, but this deep down buried code sure doesnt [16:14:32] * addshore will look at TransactionRoundDefiningUpdate and begin / commit more