As of today December 16th, M8979671 is still present in that query’s results.

This is likely a problem with the dumps; the search team will investigate to be sure and then pass it on to the right team if so.

The dumps have been investigated and the data is correct there, the problem is definitely on the search team's side. It could be with the reload scripts or nginx. It was possible to see the incorrect data on the wcqs server, so the problem is most likely with nginx.

On the wcqs beta host, curl -d "query=select * { sdc:M8979671 wdt:P571 ?o . }" localhost/bigdata/namespace/wcq/sparql returns an item with the correct data and curl -d "query=select * { sdc:M8979671 wdt:P571 ?o . }" localhost:9999/bigdata/namespace/wcq/sparql returns the 1010 date

Change 655639 had a related patch set uploaded (by ZPapierski; owner: ZPapierski):
[operations/puppet@production] Fix /sparql rewrite and alias rules

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

In T267825#6721180, @Mstyles wrote:

On the wcqs beta host, curl -d "query=select * { sdc:M8979671 wdt:P571 ?o . }" localhost/bigdata/namespace/wcq/sparql returns an item with the correct data and curl -d "query=select * { sdc:M8979671 wdt:P571 ?o . }" localhost:9999/bigdata/namespace/wcq/sparql returns the 1010 date

This is actually a correct behavior - first address resolves to a correct namespace, second simply points to an old namespace that should be used anymore (but unfortunately is). Issue is with the rewrite chaing in nginx configuration.

Change 655639 merged by Ryan Kemper:
[operations/puppet@production] Fix /sparql rewrite and alias rules

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

Issue was fixed manually for now - I'll do a proper deployment once I get some time to deal with recent microsite GUI changes.