COUNT over pattern involving limit-bound subquery: can't wait to see the results

[karlisc]

Update:
The following query
SELECT (COUNT(?x) as ?cx) WHERE { { SELECT ?x WHERE {?x ?p ?y.} LIMIT 1 } }
gives 20,853,874,240 on Wikidata QLever endpoint. It should give 1.

The behaviour was initially observed on the Uniprot QLever endpoint, but it carries over to Wikidata QLever, as well.

Original formulation:
The following query does not give the results immediately, as it most likely would be expected to.

SELECT (COUNT(?x) as ?cx) WHERE { 
{ SELECT ?x WHERE {?x a <http://purl.uniprot.org/core/Gene>. } LIMIT 1 } 
?x a ?y. }

If counting is not done on the outermost level, behavior is much more reasonable, even for higher limits.

This is observed on the Uniprot QLever dataset.

[karlisc]

A further study reveals that LIMIT is treated in a wrong way. The following query

SELECT (COUNT(?x) as ?cx) WHERE { 
{ SELECT ?x WHERE {?x a <http://purl.uniprot.org/core/Gene>. } LIMIT 1 } }

returns 6,963,288,975, although it should return 1

[karlisc]

Without counting, there is just one result, as expected.

[RobinTF]

I believe this to be a duplicate of #2404 which was fixed 5 days ago, then the results should also be given immediately.

[karlisc]

@RobinTF , it seems that the issue of #2404 on Wikidata is fixed, whereas the issue that I am reporting on Uniprot is not.
If it is just the issue of updating the Uniprot endpoint software to the newest version of QLever, when it could be expected to happen?

[karlisc]

SELECT (COUNT(?x) as ?cx) WHERE { { SELECT ?x WHERE {?x ?p ?y.} LIMIT 1 } }
gives 20,853,874,240 on Wikidata endpoint. It should give 1.
So, if I had a permission to reopen the ticket, I would have done so. @RobinTF

[RobinTF]

@karlisc Good point, please update your original post with your new query that doesn't work. These queries share the same symptoms but have different root causes.