Delayed error reply doest not work with data providers

Hello Folks,
I am trying to send error text back to confd using ‘confd_delayed_reply_error’ API when I encounter some transaction error or some other error while fetching the data.

This is how the data provider is implemented:

  1. Confd calls one of the registered API’s, get_next / get_elem etc.
  2. When we dont have the data with us, we return, ‘CONFD_DELAYED_RESPONSE’.
  3. If we encounter some error while fetching the data, I use ‘confd_trans_seterr_extended’ to set the error message followed by ‘confd_action_delayed_reply_error’.

In the ‘netconf.log’, I have this log:

30-Oct-2015::08:42:40.651 host-mc confd[15030]: netconf id=12 couldn’t retrieve all data from the data providers, closing session

I am doing a forced testing of this error path. Usually, the data fetching goes through fine.

Also, I did not find any examples for this API in the examples section as well, which makes me believe that this might not be well tested (unless I am doing something obviously wrong).

Any idea, what might be wrong ?

Thanks.

You mean ‘confd_delayed_reply_error’ here I assume?

Then in the ConfD configuration file confd.conf (from the man page):

/confdConfig/netconf/rpcErrors (close|inline) [close]
If rpcErrors is “inline”, and an error occurs during the processing of a or request when ConfD tries to fetch some data from a data provider, ConfD will generate an rpc-error element in the faulty element, and continue to process the next element.

If an error occurs and rpcErrors is “close”, the NETCONF transport is closed by ConfD.

If you set the above to “inline”, a ‘CONFD_DELAYED_RESPONSE’ followed by a ‘confd_delayed_reply_error’ with the message ‘MY ERROR STRING’ will look like this in the netconf.trace (the ConfD NETCONF trace log is enabled in confd.conf too):

<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter xmlns="http://tail-f.com/ns/example/arpe">
      <arpentries>
        <arpe>
          <ip>192.168.0.1</ip>
          <ifname>en0</ifname>
          <hwaddr/>
        </arpe>
      </arpentries>
    </filter>
  </get>
</rpc>

30-Oct-2015::19:28:01.855 **< sess:11 write:
<rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <arpentries xmlns="http://tail-f.com/ns/example/arpe">
      <rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <error-type>application</error-type>
        <error-tag>operation-failed</error-tag>
        <error-severity>error</error-severity>
        <error-message xml:lang="en">/arpe:arpentries/arpe{192.168.0.1 en0}: MY ERROR STRING</error-message>
        <error-info>
          <bad-element>arpe</bad-element>
        </error-info>
      </rpc-error>
    </arpentries>
  </data>
</rpc-reply>
1 Like

Amazing! That worked with some netconf client changes.
Should this be put along with the explanation of ‘confd_delayed_reply_error’ in the user guide ?

Noted, will add a ticket to suggest a documentation update to save other users some time and effort. Thanks!