yang-patch parsing is too strict

[jktjkt]

In RESTCONF, YANG-Patch supports targeting a resource via the HTTP-level path. When a path is then specified in an individual YANG-Patch edit, it is interpreted relative to the outer path that's provided by the URL. This has worked before libyang v5, but new anydata parsing rules in the current devel are apparently too strict because they do not know this "outer" resource path, and they try to enforce strict rules against the patch payload as-if it was run against the root datastore resource.

We have the following test in rousette which targets /example:two-leafs (via the HTTP request PATCH /restconf/data/example:two-leafs:

{
  "ietf-yang-patch:yang-patch" : {
    "patch-id" : "patch",
    "edit" : [
      {
        "edit-id" : "edit",
        "operation" : "replace",
        # note this path
        "target" : "/example:a",
        "value" : {
          "example:a" : "aaa"
        }
      },
      {
        "edit-id" : "edit",
        "operation" : "replace",
        "target" : "/example:b",
        "value" : {
          "example:b" : "bbb"
        }
      }
    ]
  }
}

My understanding of the standard is that the highlighted path actually refers to /example:two-leafs/example:a, but the current version of libyang treats it as /example:a, and therefore it applies parsing & validation rules of a container to an edit which changes the value of a leaf:

libyang[0]: Expecting JSON name/object but container "a" is represented in input data as name/string. (data path: /ietf-yang-patch:yang-patch/edit[edit-id='edit']/value, line: 11)
Validation failure: Can't parse data: LY_EVALID

The model is here, and the relevant part of the tree is:

module: example
  ...
  +--rw a
  |  +--rw b
  |  |  +--rw c
  |  |     +--rw enabled?   boolean
  |  |     +--rw blower?    string
  |  +--rw b1
  |  +--rw something?   string
  +--rw two-leafs
  |  +--rw a?   string
  |  +--rw b?   string
  ...

This used to work just fine as of commit b0a8a12. If it's important to keep the YANG-Patch parsing strict (and I definitely see value in that), then the parsing function needs some extra context option to specify which resource should act as a root via some out-of-band manner.

[michalvasko]

What exactly is the use-case please? It cannot be a normal notification validation because I cannot find any code validating this target because there is no type plugin for it.

[jktjkt]

The use case is from our RESTCONF server, a part which implements YANG-Patch, and the function which is failing is lyd_parse_data iirc:

https://gerrit.cesnet.cz/plugins/gitiles/CzechLight/rousette/+/de90dae775c2f159aefac9d393fc8c98ca002e4e/src/restconf/Server.cpp#692

The actual edit is done by our code, but before it gets a chance to run, libyang rejects the incoming JSON because it tries to parse it without relizing that “example:a” doesn’t refer to “/example:a”, but some deeper node.

[michalvasko]

Any kind of anydata context node is not supported, currently. However, the node was simply supposed to be parsed as an opaque node (you have not requested strict anydata parsing) and after the fix it is so it should work as before.

[jktjkt]

Thanks for a quick fix, just confirming that the test suite now passes.