Page MenuHomePhabricator

No namespace configured for entity type `form`
Closed, ResolvedPublic

Description

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.

Noticed in Fatal-Monitor

[XBulpgpAAK4AAK7YOp0AAAAD] /w/api.php?action=wbcheckconstraints&format=json&formatversion=2&uselang=en&id=L6515%7CL6515-F1%7CL6515-F2%7CL6515-S1&status=violation%7Cwarning%7Cbad-parameters   Wikibase\DataModel\Services\Lookup\EntityLookupException from line 88 of /srv/mediawiki/php-1.33.0-wmf.9/extensions/Wikibase/lib/includes/Store/Sql/PageTableEntityQueryBase.php: No namespace configured for entity type `form`

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 20 2018, 2:28 PM
zeljkofilipin triaged this task as Unbreak Now! priority.
Restricted Application added subscribers: Liuxinyu970226, TerraCodes. · View Herald TranscriptDec 20 2018, 2:29 PM

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

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

Pablo-WMDE added a comment.EditedDec 20 2018, 2:56 PM

Reproducible at https://www.wikidata.org/w/api.php?action=wbcheckconstraints&format=json&formatversion=2&uselang=en&id=L6515%7CL6515-F1%7CL6515-F2%7CL6515-S1&status=violation%7Cwarning%7Cbad-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}()
Tarrow claimed this task.Dec 20 2018, 3:36 PM

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.

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)

greg added a subscriber: greg.Dec 20 2018, 5:02 PM

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.

Addshore moved this task from incoming to in progress on the Wikidata board.Dec 21 2018, 10:33 AM
greg added a comment.Jan 3 2019, 11:39 PM

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

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

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

greg added a comment.Jan 7 2019, 5:33 PM

@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

@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

Addshore added a subscriber: dduvall.

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

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

Thanks for that!

Jdforrester-WMF lowered the priority of this task from Unbreak Now! to High.Jan 8 2019, 7:03 PM

Train not blocked -> not UBN.

Addshore closed this task as Resolved.Jan 8 2019, 11:07 PM

Test looks fine so closing and verifying.