Wikibase commits new in wmf.9: MediaWiki_1.33/wmf.9/Changelog#Wikibase

Only 479419 changed lib/includes/Store/Sql/PageTableEntityQueryBase.php.

Pinging people mentioned in the commit: @daniel @Addshore @Jdforrester-WMF @WMDE-leszek @Cparle

Pinging @Jakob_WMDE and @Pablo-WMDE, since the rest of the Wikidata team is already out for the holidays. Pinging @Lucas_Werkmeister_WMDE, since he probably knows most about wbcheckconstraints.

Quick assessment: my patch introduced the check that now throws an error. This would have failed silently before. So the error itself is not new. The problem is that forms are not "top level" entities. I'm not sure what the current approach is to resolving IDs of "sub-entities".

Reproducible at https://www.wikidata.org/w/api.php?action=wbcheckconstraints&format=json&formatversion=2&uselang=en&id=L6515|L6515-F1|L6515-F2|L6515-S1&status=violation|warning|bad-parameters (assuming no harm done)

Context: This is a request e.g. performed on wikibase entity pages post statement save to check for constraint violations. Introduced during T195829
It "worked at the time", question being what does PageTableEntityQueryBase even do for use in this case?

TLDR: because this is a new error, it's blocking the train. Since people are already on vacation or leaving soon, I need to know if it's fine to move the train forward with this, or not.

This is the stack trace I get locally by passing any form id into wbcheckconstraints:

PageTableEntityQueryBase.php:85, Wikibase\Lib\Store\Sql\EntityIdLocalPartPageTableEntityQuery->getQueryInfo()
PageTableEntityQueryBase.php:53, Wikibase\Lib\Store\Sql\EntityIdLocalPartPageTableEntityQuery->selectRows()
WikiPageEntityMetaDataLookup.php:336, Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->selectLatestRevisionIdsMultiple()
WikiPageEntityMetaDataLookup.php:170, Wikibase\Lib\Store\Sql\WikiPageEntityMetaDataLookup->loadLatestRevisionIds()
CachingResultsSource.php:466, WikibaseQuality\ConstraintReport\Api\CachingResultsSource->getLatestRevisionIds()
CachingResultsSource.php:301, WikibaseQuality\ConstraintReport\Api\CachingResultsSource->storeResults()
CachingResultsSource.php:251, WikibaseQuality\ConstraintReport\Api\CachingResultsSource->getAndStoreResults()
CachingResultsSource.php:179, WikibaseQuality\ConstraintReport\Api\CachingResultsSource->getResults()
CheckConstraints.php:179, WikibaseQuality\ConstraintReport\Api\CheckConstraints->execute()
ApiMain.php:1595, ApiMain->executeAction()
ApiMain.php:531, ApiMain->executeActionWithErrorHandling()
ApiMain.php:502, ApiMain->execute()
api.php:87, {main}()

The plan is to revert 479419.

See: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/ /480978 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/ /480966

For the record, the revert should be temporary, on the deployment branch, not on master. This is exposing a problem in the calling code, which needs to be addressed. The revert is not a proper fix, just a stop-gap.

In T212427#4838130, @daniel wrote:

For the record, the revert should be temporary, on the deployment branch, not on master. This is exposing a problem in the calling code, which needs to be addressed. The revert is not a proper fix, just a stop-gap.

Cool. From IRC: @zeljkofilipin will deploy the backport, we will not merge the revert to master and releng will make sure they don't forget about it.

With my wikidata incident manager hat on I'll make sure we work on a proper fix ASAP (but obviously holidays might slow it down a bit)

Mentioned in SAL (#wikimedia-operations) [2018-12-20T16:51:55Z] <zfilipin@deploy1001> Synchronized php-1.33.0-wmf.9/extensions/Wikibase: SWAT: [[gerrit:480978|Revert "Fail hard if an entity namespace is not configured." (T212427)]] (duration: 01m 17s)

In T212427#4838160, @Stashbot wrote:

Mentioned in SAL (#wikimedia-operations) [2018-12-20T16:51:55Z] <zfilipin@deploy1001> Synchronized php-1.33.0-wmf.9/extensions/Wikibase: SWAT: [[gerrit:480978|Revert "Fail hard if an entity namespace is not configured." (T212427)]] (duration: 01m 17s)

removing this as a blocker to the wmf.9 train then, leaving for the next train after holiday break.

In T212427#4838149, @Tarrow wrote:

In T212427#4838130, @daniel wrote:

For the record, the revert should be temporary, on the deployment branch, not on master. This is exposing a problem in the calling code, which needs to be addressed. The revert is not a proper fix, just a stop-gap.

Cool. From IRC: @zeljkofilipin will deploy the backport, we will not merge the revert to master and releng will make sure they don't forget about it.

With my wikidata incident manager hat on I'll make sure we work on a proper fix ASAP (but obviously holidays might slow it down a bit)

@Tarrow The next train is branching in 2 work days (on Tuesday Jan 8th). Please do the needful :)

Change 482289 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/WikibaseQualityConstraints@master] Use EntityRevisionLookup for revision lookups

https://gerrit.wikimedia.org/r/482289

Link for testing on beta once merged.

https://wikidata.beta.wmflabs.org/w/api.php?action=wbcheckconstraints&format=json&formatversion=2&uselang=en&id=L6515|L6515-F1|L6515-F2|L6515-S1&status=violation|warning|bad-parameters

Change 482653 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/WikibaseLexeme@master] Introduce MediaWikiPageSubEntityMetaDataAccessor

https://gerrit.wikimedia.org/r/482653

@Tarrow day before the new branch cut :)

Change 482768 had a related patch set uploaded (by Tarrow; owner: Tarrow):
[mediawiki/extensions/Wikibase@master] Rename repo metdata accessor and return TypeDispatching variant

https://gerrit.wikimedia.org/r/482768

Change 482289 abandoned by Tarrow:
Use EntityRevisionLookup for revision lookups

Reason:
as per addshore's -1

https://gerrit.wikimedia.org/r/482289

In T212427#4859961, @greg wrote:

@Tarrow day before the new branch cut :)

The patches for the fix are currently 2ed and in the process of being merged.

Change 482768 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Rename repo metdata accessor and return TypeDispatching variant

https://gerrit.wikimedia.org/r/482768

Change 482653 merged by jenkins-bot:
[mediawiki/extensions/WikibaseLexeme@master] Introduce MediaWikiPageSubEntityMetaDataAccessor

https://gerrit.wikimedia.org/r/482653

@greg @dduvall train is unblocked now, verified on beta.

In T212427#4862694, @Addshore wrote:

@greg @dduvall train is unblocked now, verified on beta.

Thanks for that!