Why I keep getting "capabilities-changed" error from confd?

In my design, there are some new fxs files and I do in service upgrade. After the upgrade completed (succeeded), I can see the expected schema shown using confd_cli.

When I try to lock the confd candidate datastore, I keep getting the error response:

There is NO changes in confd.conf about before and after upgrade. The only changes in confd.conf is adding new load path. I also try to restart confd. But I will still get the same error response.

Any idea why confd keep complaining “capabilities-changed” ?


It seems I can’t find any reference what should check to fix this error…
Any idea would be appreciated. Thanks

If you do such an upgrade, at least for YANG 1 modules, the <capabilities> as reported in the NETCONF <hello> message will have changed. I’m not clear on whether this is specified in an RFC, but in any case the idea with the capabilities-changed error is to inform the client that the capabilities have changed since it received the <hello> message from the server - the implication is that the client should terminate the current session and start a new one, to get the current capabilities. Do you get the error even in a session that is started after the upgrade has completed?

Is this restart done without doing a data model upgrade?

If it keeps complaining across restarts without upgrade, or in new sessions started after the upgrade has completed, it would be a bug - but it seems to me that it’s highly unlikely that this behavior exists. Otherwise, I believe it is working as designed.

I think what you mentioned is the reason cause issue. In the design, it looks like we keep using the existed session which is established before upgrade. But I need to double check.

After restart, I think the upgrade be done again since the design of backend service. But again I need double check.

Thank you very much. What you recommend gave a direction where I should start investigating!