This issue is currently waiting on two changes:

• rEBQCcb60e6b34766: Add tracking for type checker SPARQL fallback, once deployed, should let us know if the SPARQL fallback works at all.
• T168938: Configure WikibaseQualityConstraints extension on Wikidata, once merged, should make the fallback happen a lot sooner, hopefully improving type checking performance.

If that doesn’t help, I’ll have to look into other ways to investigate this.

Seems to work a lot better now – at least, books are now properly recognized as works. (Note that Douglas Adams and some other items currently don’t work at all due to T171295: Fatal error: Argument 4 passed to WikibaseQuality\ConstraintReport\Constraint::__construct() must be array, but that’s unrelated.)

Thanks for merging this with T171933.

I think it would be better if the timeout would be displayed as such, not as a constraint violation.

Ooooooh. I think I finally realized what’s happening. Let’s take The Private Life of Genghis Khan, a short story that gets constraint violations because it’s supposedly not a book.

• The TypeCheckerHelper takes The Private Life of Genghis Khan’s P​31 statement – short story – and checks if it is a subclass of work.
• Since the limit for type checks in PHP has not yet been reached, TypeCheckerHelper takes the first P​279 statement – prose – and checks if that is a subclass of work.
• TypeCheckerHelper descends into prose’s type hierarchy. Eventually, at some unknown superclass (say, literary genre), it reaches the limit for type checks.
• Since the limit has been reached and a SparqlHelper is configured, TypeCheckerHelper falls back to SPARQL. It asks if literary genre is a subclass of work.
• SPARQL tells us (correctly) that literary genre isn’t a subclass of work.
• TypeCheckerHelper walks back the stack of subclass checks, returning false on each level. At no level is the SparqlHelper consulted again, because we don’t want to spam WDQS.
• Eventually, TypeCheckerHelper has fallen back to short story. It checks the next P​279 statement: literary work.
• Since the limit for type checks has already been exceeded, the check returns false immediately (and since the limit was already exceeded earlier, not in this call, the SPARQL fallback doesn’t happen either).
• In the end, TypeCheckerHelper returns false for the overall check.

The SPARQL fallback needs to happen at the outermost level, not at the first subtype check that exceeds the limit.

So one could try "fix" it by re-ordering the P 279 statements. ;)

Ideally, most values used for P 31 would have several P 279 statements.

Change 368664 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/WikibaseQualityConstraints@master] Fix type checking SPARQL fallback

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

Change 368664 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Fix type checking SPARQL fallback

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

Change 369429 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikidata@wmf/1.30.0-wmf.12] Update Wikidata - fix constraint type checks

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

Change 369555 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikidata@master] Update Wikidata - fix constraint type checks

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

Change 369555 abandoned by Lucas Werkmeister (WMDE):
Update Wikidata - fix constraint type checks

Reason:
Sorry, pushed to wrong refs/for/ path – this belongs on wmf/1.30.0-wmf.12.

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

Change 369429 merged by jenkins-bot:
[mediawiki/extensions/Wikidata@wmf/1.30.0-wmf.12] Update Wikidata - fix constraint type checks

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

Mentioned in SAL (#wikimedia-operations) [2017-08-02T13:07:18Z] <hashar@tin> Synchronized php-1.30.0-wmf.12/extensions/Wikidata: fix constraint type checks - T169326 (duration: 02m 13s)

Unfortunately, the Wikidata deployment was rolled back due to unrelated problems in Wikibase itself, so the false violations are back for the time being. If the build problem persists, I might try to get the fix backported, otherwise we’ll just have to wait it out – sorry.

I am confused about this issue is it fixed or is it still a problem? Is the task is "resolved" but the fix is not deployed yet?

I came to phabricator to report an issue I noticed today with "type constraint " d:Wikidata:Database reports/Constraint violations/P1472 reports a constraint violation based on an item that is an instance of "newspaper", which is a subclass of "media company", which is a subclass of "organization", which is on a list of approved types for the constraint. Is this a new issue for which I should create a new ticket, or is this issue still unresolved?

The fix was deployed a long time ago, this bug is resolved. But regardless of that, whatever you’re seeing on d:Wikidata:Database reports/Constraint violations is KrBot’s business – the WikibaseQualityConstraints extension (which this bug is about) has nothing to do with that. Do you also see the constraint violation on d:Special:ConstraintReport or when looking at the item with the checkConstraints gadget enabled?

In T169326#3679598, @Lucas_Werkmeister_WMDE wrote:

Do you also see the constraint violation on d:Special:ConstraintReport or when looking at the item with the checkConstraints gadget enabled?

No I do not. I will check with KrBot.