XPath `//top-level-node` never matches module top-level containers

[DennisChiuEC]

Hi, I am meeting some issues when using the filter "xpath".

Summary

The abbreviated XPath expression //foo fails to match foo when foo is a module's top-level node (container / leaf / list).
The explicit equivalent /descendant-or-self::node()/foo succeeds on the same server against the same data.

Reproduced against libyang v5.4.9.

Reproducer

Environment: any sysrepo installation that has loaded the stock ietf-netconf-acm module (this ships with sysrepo by default).

# Version info from my reproduction environment:
#   libyang     v5.4.9
#   sysrepo     v4.5.4
#   OS          Debian 12 (bookworm), inside docker

# 1) SUCCESS - absolute path
sysrepocfg -X -x '/ietf-netconf-acm:nacm' -d running
# → returns the <nacm> element with all its children

# 2) SUCCESS - explicit descendant-or-self axis (equivalent to '//' per XPath 1.0)
sysrepocfg -X -x '/descendant-or-self::node()/ietf-netconf-acm:nacm' -d running
# → returns the same <nacm> element

# 3) FAIL - '//' shortcut, semantically equivalent to (2)
sysrepocfg -X -x '//ietf-netconf-acm:nacm' -d running
# → [ERR] Schema node "nacm" for parent "<root>" not found;
#         in expr "//ietf-netconf-acm:nacm" with context node "/".
# → sysrepocfg error: Getting data failed (Item not found)

Note that the //foo form does succeed when foo is NOT a module top-level node:

# SUCCESS - '//deep-node' finds enable-nacm because it is nested under /nacm
sysrepocfg -X -x '//ietf-netconf-acm:enable-nacm' -d running

So the bug is specifically the combination:

• // shortcut is used, AND
• the target NCName is a module top-level schema node.

Is it expected that "//" should work for xpath?
Thanks

[michalvasko]

Weird and old bug but should now be fixed in devel.