Missing values in cdb_get_modifications subscription notification in confd 7.2.1 basic

When I create a reasonably large, reasonably complex object I am finding that not all values are being included the result array of cdb_get_modifications. As one example where it happens, the values_cnt output parameter should be 142 but 140 values are produced instead.

I know that the values are actually in the model because when I execute "netconf-console --get-config -x /path_to_object I see the values. Additionalyl, I’ve built my subscription handler off of the examples/cdb_subscription/modifications/modif-printer.c and the document that it produces is not the same as the xml-output from netconf-console --get_config.

This happens only for a few of the larger objects in my model. The values dropped are typically part of a container whose other components include a choice. To be clear, the dropped values are peers of the choice.

While I am trying to produce a simple example that reproduces this, are there any known issues with partial data being delivered to the cdb_get_modifications for a create event? I am currently running 7.2.1 but can update to 7.3 basic as part of the troubleshooting.

Thanks,

Dave

Not that I am aware of. I would suspect that the problem lies in the modif-printf.c example.
You’ll find a better demo/example from the link below that output actual NETCONF XML.

Thank you for your response.

I have a few additional pieces of information, but unfortunately, not a simple example yet.

1.) I’ve upgraded to 7.3 and the behavior is the same.
2.) The missing notifications are part of a grouping that appears in the model 8 times. I am notified for the common element 6 times.
3.) If I “unfactor” the common element and replace the “uses” in the grouping in the missing elements with elements that all have unique names, I get all 8 notifications.

Roughly I have

grouping user_choice {
    leaf user_choice {
      config true;
      type string;
    }
 }


grouping Level1 {
      container level1_Config {
        uses a_choice;
        uses user_choice;
      }
      container level2_Config {
        uses b_choice;
        uses user_choice;
      }
      container level3_Config {
        uses c_Config_choice;
        uses user_choice;
      }
      container level4_Config {
        uses user_choice;
      }
    }
....

That repeats 8 times for where I get the problem. If I replace the “uses user_choice” with “leaf user_choice { type string;}” I still have the problem. If I replace that with leaf user_choice_tag_1 { type string;} (and tag each element uniquely user_choice_tag_n, I DO NOT get the problem.

I.E. there seems to be a dependency on the name of element or the repetition of the use of “user_choice”. Of course there could be an error in my code or model, but I do not get an error compiling the yang models nor when I populate them with data. I just don’t get a full notification set on create. No errrors in develop.log, netconf.log or anywhere else that I’ve seen

My first attempt at simplifying the model did not elicit the behavior so I am still trying to create an example that illustrates the problem.

If it is of relevance, we also rebuild the library with a -DMAXDEPTH=32 -DMAXKEYLEN=16

Thanks for the help and I will endeavor to produce a simpler model that I can share that illustrates this problem.

It is good to know that groupings etc. will not be a factor after compiling your YANG models with confdc. They will be expanded in the schema that is used by CDB.
Hence replacing “uses” with the contents of the grouping will not make a difference.

Also note that a NETCONF <get> will get all the configuration, not just the modifications.
One way to get all the configuration through a subscriber is to trigger the subscription(s) using cdb_trigger_subscriptions().
An easy way to do this is to use the confd_cmd tool. E.g.

$ confd_cmd -dd -c 'trigger_subscriptions'

So you can for example use the confd_cmd tool to subscribe and get the modifications when triggered and then trigger the subscriber from another process / thread:

$ pwd
/Users/tailf/confd-7.3.1/examples.confd/intro/1-2-3-start-query-model
$ make all; confd -c confd.conf --addloadpath /Users/tailf/confd-7.3.1/etc/confd
$ confd_cmd -dd -c 'mset /dhcp/default-lease-time P42H'
mset "/dhcp/default-lease-time" "P42H"
TRACE Connected (maapi) to ConfD
TRACE MAAPI_START_USER_SESSION  --> CONFD_OK
TRACE MAAPI_START_TRANS  --> CONFD_OK
TRACE MAAPI_SET_ELEM2 /dhcp/default-lease-time --> CONFD_OK
TRACE MAAPI_APPLY_TRANS  --> CONFD_OK
TRACE MAAPI_STOP_TRANS  --> CONFD_OK
TRACE MAAPI_END_USER_SESSION  --> CONFD_OK
$ confd_cmd -dd -c 'subwait_mods "/dhcp" 1 100 "/dhcp" "suppress_defaults"' &
subwait_mods "/" "1" "100" "suppress_defaults"
TRACE Connected (maapi) to ConfD
TRACE MAAPI_LOAD_ALL_NS
TRACE MAAPI_LOAD_MNS_MAPS
TRACE MAAPI_LOAD_HASH_DB
TRACE Connected (cdb) to ConfD
TRACE CDB_SUBSCRIBE / --> CONFD_OK
TRACE CDB_SUBSCRIBE_DONE  --> CONFD_OK
SUBSCRIBED TO /
$ confd_cmd -dd -c 'trigger_subscriptions'
trigger_subscriptions
TRACE Connected (cdb) to ConfD
TRACE CDB_TRIGGER_SUBS TRACE CDB_SUBSCRIPTION_EVENT --> 7
COMMIT
TRACE CDB_GET_MODIFICATIONS  --> CONFD_OK
default-lease-time P0DT42H
TRACE CDB_SYNC_SUB CDB_DONE_PRIORITY --> CONFD_OK
DONE
 --> CONFD_OK