ConfD User Community

Get-next is being called multiple times with next (-1)

Hi,

I have a nested list with a single tailf callpoint as shown below.

While executing the “show RMANB du riu”, I do get the get_next call multiple
times with -1 even though all the keys values are set and sent back to Confd on the 1st call itself.

258     CONFD_SET_IPV4(&v[0], curr->ip4);
259     CONFD_SET_STR(&v[1], curr->iface);
260     confd_data_reply_next_key(tctx, &v[0], 2, (long)curr->next);

Would appreciate any feedback on why I am getting so.

===============Log Trace==============================

TRACE CALL data get_next(thandle=202, /RMANB/du, -1) 
----------------->Set Keys!!
 --> CONFD_OK
TRACE CALL data get_next(thandle=202, /RMANB/du, -1) 
----------------->Set Keys!!
  --> CONFD_OK
TRACE CALL data get_next(thandle=202, /RMANB/du{10.24.12.1 ens32}/riu, -1) 
----------------->Set Keys!!
 --> CONFD_OK
TRACE CALL data get_next(thandle=202, /RMANB/du{10.24.12.1 ens32}/riu, -1) 
----------------->Set Keys!!
 --> CONFD_OK
TRACE CALL data get_elem(thandle=202,/RMANB/du{10.24.12.1 ens32}/riu{10.24.12.1 ens32}/hwaddr)
 
 ("e8:f7:24:9d:3e:64")  --> CONFD_OK
......
=======================YANG ========================

  container RMANB {
    config false;
    **tailf:callpoint du;**
    list du {
      key "ip ifname";
      max-elements 1024;
      leaf ip {
        type inet:ip-address;
      }
      leaf ifname {
        type string;
      }
      leaf hwaddr {
        type string;
        mandatory true;
      }
      list  riu {
        key "ip iface";
        max-elements 1024;
        leaf ip {
           type inet:ip-address;
        }
        leaf iface {
          type string;
        }
        leaf hwaddr {
          type string;
        }
      }
    }
  }

Note:
Reference- confd-7.3.1/examples.confd/intro/5-c_stats.

Thank you in advance.

Regards,
Haripriya

As per the comment in one of the earlier post getting (-1) multiple times is not a problem as long as its being handled properly.

Please do let me know if I am missing something here.

Yes, your data provider callbacks should not make any assumptions about how often the iteration can be restarted; and in particular in case of CLI it is always the case that a command like show RMANB du riu causes two get_next(-1) invocations.