Snmp walk get_next doesn't invoke get_object of last entry

Other Northbound Interfaces
1

Hi,

I’m doing an snmp walk on list. The last entry is always missing in the output. As highlighted below, It turns out that a valid get_next() call is not resulting into the invokation of get_object(). What could be the issue and any pointers on how to debug this further?

TRACE New user session: 81 for user:public ctx:snmp → CONFD_OK
TRACE CALL trans init(thandle=228,mode=“r”,db=running)TRACE MAAPI_ATTACH → CONFD_OK
→ CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, -1) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 58 one}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 249108103168) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 59 two}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 253403070464) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 60 three}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 257698037760) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 61 four}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 261993005056) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 62 five}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 266287972352) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 63 six}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 270582939648) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 64 seven}) → CONFD_DELAYED_RESPONSE
TRACE CALL data get_next(thandle=228, /test/test-targets, 274877906944) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 65 eight}) → CONFD_DELAYED_RESPONSE

TRACE CALL data get_next(thandle=228, /test/test-targets, 279172874240) → CONFD_OK
/* —> Missing get_object() call here <---- */

TRACE CALL data get_next(thandle=228, /test/test-targets, -1) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 249108103168) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 253403070464) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 257698037760) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 261993005056) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 266287972352) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 270582939648) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 274877906944) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 279172874240) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, 287762808832) → CONFD_OK
TRACE CALL data get_next(thandle=228, /test/test-targets, -1) → CONFD_OK
TRACE CALL data get_object(thandle=228,/test/test-targets{10.10.5.10 58 one}) → CONFD_DELAYED_RESPONSE

2

To debug data provider issues you want to check the ConfD daemon developer log (developerLogLevel trace in confd.conf) and the data provider application libconfd trace log (that you show in your post above).
I.e. compare output from the data provider application libconfd trace log with the ConfD daemon log.