[BUG] XQuery fails to select node with true predicate

[Twilight-Shuxin]

Describe the bug A clear and concise description of what the bug is. Give XML document

<F id="1"/>

and XPath Query

//F[boolean(count(@id >= 2))]

eXist returns 0 element

Expected behavior A clear and concise description of what you expected to happen.

Should return F node as count(false()) = 1 and boolean(1) = true() Executing //F/boolean(count(@id >= 2)) in eXist returns true as expected.

To Reproduce

xquery version "3.1";

module namespace t="http://exist-db.org/xquery/test";

declare namespace test="http://exist-db.org/xquery/xqsuite";

declare variable $t:XML := document {
    <F id="1"/>
};

declare
    %test:setUp
function t:setup() {
    xmldb:create-collection("/db", "test"),
    xmldb:store("/db/test", "test.xml", $t:XML)
};

declare
    %test:tearDown
function t:tearDown() {
    xmldb:remove("/db/test")
};

declare
    %test:assertTrue
function t:test-db() {
    exists(
        doc("/db/test/test.xml")//F[boolean(count(@id >= 2))]
    )
};

declare
    %test:assertTrue
function t:test-mem() {
    exists(
        $t:XML//F[boolean(count(@id >= 2))]
    )
};

Context (please always complete the following information)

• Build: latest development version built from source, commit efb1498
• Java: 17
• OS: [Windows]

Additional context

• How is eXist-db installed? Jar installer
• Any custom changes in e.g. conf.xml? No

[duncdrum]

Changing the Xpath to F[boolean(count(data(@id) >= 2))] actually returns the expected results in memory and from db. Saxon returns true without changing @id to data(@id) so still a bug it seems

[line-o]

@Twilight-Shuxin Thanks again for reporting another issue. @duncdrum your finding could be very helpful in finding the root cause.

[duncdrum]

also tested with 6.2.0 same results.

[adamretter]

Just to make it explicit. There are two tests in @Twilight-Shuxin's report. Only one of them fails, t:test-db#0, the other t:test-mem#0 (which uses the in-memory DOM as opposed to the persistent DOM) passes just fine.

I suspect, but have not confirmed, that this result is likely caused by a bad optimisation path in eXist-db.