Remove data in operational callback

[rbu9fe]

I'm registering an operational callback with the SR_SUBSCR_OPER_MERGE flag set. The goal now is to to treat a config leaf in the operational callback since its reported status may be different than the configured value. For example, when the config leaf is existing I want to

1. change its value, or
2. delete it from the operational datastore.

Changing its value is simple, however, I can't find a way to delete it when the SR_SUBSCR_OPER_MERGE flag is set. I tried to remove it by annotating the leaf with a remove tag in the output of the callback like

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "eno0",
        "ieee802-ethernet-interface:ethernet": {
          "speed": "1.0",
          "@speed": {
            "ietf-netconf:operation": "remove"
          }
        }
      }
    ]
  }
}

However, clients still read that speed leaf as:

{
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "eno0",
        "ieee802-ethernet-interface:ethernet": {
          "speed": "1.0"
        }
      }
    ]
  }
}

So the annotation is not considered when merging the output of the operational callback.

Is that considered a bug or is it just not supported?

Alternatively, I could directly manipulate the operational data if sysrepo provided that with the callback already. Then I would not have to let sysrepo merge the trees but let the callback change the data directly. But in the sysrepo callback's incoming data the children of the requested path are cleared.

What is the preferred way how to remove something from the operational datastore while keeping the SR_SUBSCR_OPER_MERGE flag set? I'm still using libyang 2.1.148. Is this perhaps solved already with libyang 3?

[michalvasko]

There are no changes to this feature in newer versions and you simply cannot get this functionality with the flag SR_SUBSCR_OPER_MERGE set, which I would consider expected. So just register a callback for this leaf only, without the flag, and it should work. Other than that it is difficult, you could perhaps use push oper data but that does not seem like a good idea.

[rbu9fe]

In my current design it's difficult to register a dedicated callback for that leaf since it has dependencies to other leafs (sharing some same context to extract the leaf's data from), so I changed it using oper push data which works as expected.