Looks like Belgium is back to Q31 and cats are cats again. I will investigate what happened to the URIs (most likely the order in the dictionary switched somehow because of changing of underlying storage class but I have missed it since the content of the dictionary is still the same).

Furthermore, https://query.wikidata.org/css/embed.style.min.fa3ff6a142279256ede4.css gives 404

Works fine for me.

Change 530463 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[wikidata/query/rdf@master] Fix prefixes order - it was P, then Q

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

Still getting a few dozens of wdt:Pxxx, query:

SELECT * { ?obj wdt:P3083 [] FILTER(STRSTARTS(STR(?obj),"http://www.wikidata.org/entity/P")) }

Another example, currently has 101 results:

SELECT ?item WHERE {
  ?item wdt:P495 [] .
  {{ FILTER NOT EXISTS { ?item wdt:P161 [] }} UNION { FILTER NOT EXISTS { ?item wdt:P364 [] }}}
  FILTER(STRSTARTS(STR(?item), "http://www.wikidata.org/entity/P"))
}

Change 530463 merged by jenkins-bot:
[wikidata/query/rdf@master] Fix prefixes order - it was P, then Q

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

I think all the items that were updated during the breakage, and were not updated since then, would be broken now – their data was imported using the swapped Ps and Qs, and then after the fix it’s swapped the wrong way. We should be able to get a list of all potentially affected items from recentchanges (Quarry) – @Smalyshev is it possible to tell the updater to re-import those specific entities?

I definitely can re-import mine, but existing wdt:Pxxx makes operating existing bots much more difficult than it should be

In T230588#5419320, @Lucas_Werkmeister_WMDE wrote:

I think all the items that were updated during the breakage, and were not updated since then, would be broken now – their data was imported using the swapped Ps and Qs, and then after the fix it’s swapped the wrong way. We should be able to get a list of all potentially affected items from recentchanges (Quarry) – @Smalyshev is it possible to tell the updater to re-import those specific entities?

Can confirm. By deleting and immediately re-creating value pairs I see the error disappear.

Mine wdt:P disappear

This query https://query.wikidata.org/#SELECT%20%3Fprop%20%3Ftype%20WHERE%20%7B%20%3Fprop%20wikibase%3ApropertyType%20%3Ftype%20FILTER%20%28CONTAINS%28STR%28%3Fprop%29%2C%22Q%22%29%20%26%26%203%21%3D1%29%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%7D still returns wrong results. Has WDQS not updated yet?

Hmm looks like I updated all Qs but forgot about some Ps... These should be fine now.

Change 531985 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[wikidata/query/rdf@master] Fix initials order

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

Change 531985 merged by jenkins-bot:
[wikidata/query/rdf@master] Fix initials order

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

I'm still getting this with "normal" properties (ie not just wikibase:quantityUnit) on https://www.wikidata.org/wiki/Q334443 - it's showing up as a duplicate as 'P334443' in P39-based searches which return the item, and I can replicate this just with a targeted search by identifier (https://w.wiki/825).

I've tried editing the item, or deleting and recreating some claims, but it doesn't seem to affect the query results.

On the plus side, this is the only one I've found in a test run of ten thousand or so, so it seems to be a rare problem...

See T232212#5472285 / Wikitech for update instructions (needs to be done by someone with WDQS production access, which I don’t have as far as I’m aware).

In T230588#5474345, @Lucas_Werkmeister_WMDE wrote:

See T232212#5472285 / Wikitech for update instructions (needs to be done by someone with WDQS production access, which I don’t have as far as I’m aware).

@Mathew.onipe : could you have a look into this? The easiest is probably to do a full data reload on wdqs1010 and copy it to each server.

If we’re going to do a full data reload, can we perhaps wait for T174504 to settle first? That would also be solved by a full reload, I believe, and might be very difficult to fully clean up without one.

(TL;DR: we’re now exporting coordinate values with reduced precision, but that doesn’t affect the hash of value nodes, so now we have some full-precision and some reduced-precision coordinate value nodes. Personally I think that change should be reverted, but even if we decide against that, the inconsistency should still be resolved.)

It seems unlikely that T174504 will be resolved soon-ish. Doing a full data reload isn't all that expansive, we can do another one once T174504 is fixed.

Change 540153 had a related patch set uploaded (by Mathew.onipe; owner: Mathew.onipe):
[operations/cookbooks@master] wdqs: add data-reload cookbook

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

In T230588#5537000, @Gehel wrote:

It seems unlikely that T174504 will be resolved soon-ish.

We’ve reverted the problematic change now, so if you do the reload from this week’s RDF dumps (or later), that should resolve that issue for now. (Though that doesn’t mean the issue is fully resolved yet – it just solves the inconsistent data we currently have.)

Change 540153 merged by Gehel:
[operations/cookbooks@master] wdqs: add data-reload cookbook

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

Change 546194 had a related patch set uploaded (by Mathew.onipe; owner: Mathew.onipe):
[operations/cookbooks@master] wdqs: do not use external mirror

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

Change 546194 merged by Gehel:
[operations/cookbooks@master] wdqs: do not use external mirror

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

Change 547158 had a related patch set uploaded (by Mathew.onipe; owner: Mathew.onipe):
[wikidata/query/deploy@master] Provide classpath via absolute path

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

Change 547510 had a related patch set uploaded (by Mathew.onipe; owner: Mathew.onipe):
[wikidata/query/rdf@master] Provide classpath via absolute path to munge and runUpdate scripts

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

Change 547158 merged by Gehel:
[wikidata/query/deploy@master] Provide classpath via absolute path to munge and runUpdate scripts

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

Change 547510 merged by jenkins-bot:
[wikidata/query/rdf@master] Provide classpath via absolute path to munge and runUpdate scripts

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

Also wikibase:quantityUnit is affected by this - unless the strange results of this query is caused by something else:

SELECT ?item ?itemLabel ?amount ?unit ?unitLabel
WHERE
{
  VALUES ?item { wd:Q20414458 }
  ?item p:P2048/psv:P2048 _:heigth .
  _:heigth wikibase:quantityAmount ?amount .
  _:heigth wikibase:quantityUnit ?unit .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . }
}

Results:

Full reimport is in progress. By the look of it, it will still take around a week to catch up on lag on wdqs1010 before we can copy the data over to other servers.

By the looks of the lag it seems like the import has finished.
Running the query provided by @Dipsacus_fullonum a couple of times (with slight variations to "trick" the cache), the unit wd:P174728 is still present in the result of all runs.
Does that mean that wdqs1010 is not part of the pool for public queries, or that the invalid values made it into the dumps?

wdqs1010 is one of our test / admin / maintenance server, but not part of any public server pool. Now that the data is up to date on wdqs1010, we need to replicate it to all servers. We have a new team member starting soon, and that's going to be his first task. So this is not completed yet, but should be reasonably soon.

Thanks for the explanation and welcome to the new team member.

Just in case you need more queries to test this:

select * {
  ?s prov:wasDerivedFrom/pr:P248 wd:P51905050
} LIMIT 10

Looks like the test queries above are all returning the "normal" expected results now - hopefully this means the reload has fixed things!

(@Mmarx's one with P495 returns some P-values, but they all seem legitimate - all six of those properties do indeed have a P495 value.)