`edit-data` with `merge` as a default operation against the `candidate` DS fails when trying to set a value from a non-default choice

[jktjkt]

I'm coming from CESNET/netconf-cli#26. When I try to set a case node to a non-default value in the candidate DS, I get back an error that multiple cases exist. Here's a minimal model (bug-default.yang):

module bug-default {
  namespace bd;
  prefix bd;
  container blah {
    choice mode {
      default off;
      leaf off {
        type empty;
        default "";
      }
      leaf a {
        type uint8;
        mandatory true;
      }
    }
  }
}

This is what netopeer2-cli reports for (get-data --datastore running --defaults report-all-tagged --filter-xpath /bug-default:blah):

<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <blah xmlns="bd">
    <off xmlns:ncwd="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults" ncwd:default="true"/>
  </blah>
</data>

for candidate:

<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <blah xmlns="bd">
    <off xmlns:ncwd="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults" ncwd:default="true"/>
  </blah>
</data>

and finally for startup:

<data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
  <blah xmlns="bd">
    <a>10</a>
  </blah>
</data>

Then the following operation:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="9">
  <edit-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda">
    <datastore xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">ds:candidate</datastore>
    <default-operation>merge</default-operation>
    <config>
      <blah xmlns="bd">
        <a>10</a>
      </blah>
    </config>
  </edit-data>
</rpc>

fails with this error:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="10">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>operation-failed</error-tag>
    <error-severity>error</error-severity>
    <error-message xml:lang="en">Data for both cases "off" and "a" exist. (path "/bug-default:blah/mode")</error-message>
  </rpc-error>
</rpc-reply>

The same edit works fine against the startup DS, so I think that there's something strange in how the candidate DS edits are implemented.

[michalvasko]

So I have tried this but did not reproduce it, the edit-data succeeds. But my guess is that you meant that the following commit fails with this error because it does. I am not exactly sure what to do about this because it is mostly intentional. You can modify candidate however you want, it may not be valid but is validated after copying it to another datastore, hence the observed behavior. I do not think it makes much sense performing only some validation tasks (such as auto-deleting duplicate cases) and libyang does not have support for this, anyway.