Page MenuHomePhabricator

No namespace configured for entity type `form`
Closed, ResolvedPublicPRODUCTION ERROR

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

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

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}()

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)

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.

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

@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

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

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:08 PM