sr_oper_get_subscribe returning SR_ERR_INVAL_ARG for specific yang model

[zdevcic]

Hello,

we are using netopeer2 v2.1.59 and on attempt to subscribe for oper data we are getting SR_ERR_INVAL_ARG. It is happening for specific yang model only:

vendor-specific-thresholds.yang.txt

Error is returned for the first leaf: using-vswr-major-threshold.

What we find significant here is that leafs of container using-vswr-thresholds are all read-only, but container itself is not specified as read only (so it is read-write by default). With such yang model we get SR_ERR_INVAL_ARG.

But, if we specify container using-vswr-thresholds as read only, then all works fine and no issues.

Is this a bug present here, since attached yang model which is triggering error is generally allowed as well?

Thank you.

[michalvasko]

What is the error message? Enable logging by calling sr_log_stderr(SR_LL_ERR).

[zdevcic]

Error we are getting is:

[ERR] Operational get subscription for XPath "/vendor-specific-thresholds:vswr-thresholds/using-vswr-thresholds/using-vswr-major-threshold" already exists and SR_SUBSCR_OPER_MERGE not used.

Really not sure why it says that subscription already exists, because this is the first and only attempt of it, I have checked my code and traces to verify this detail.

Also, as already mentioned, declaring related container using-vswr-thresholds as "config false;" in the yang resolves the issue. Hard to relate the way we avoid/resolve the issue with error description we get.

[jktjkt]

Please post your code on how exactly you are creating that subscription.

[zdevcic]

I use same approach for all XPaths in the app, number of them, at all other places it works fine except this one.

[michalvasko]

You can verify there is no other subscription by looking into the data returned by sysrepocfg -X -d operational -m sysrepo-monitoring because it does not really makes sense that this is the only case when an invalid error is generated.

[zdevcic]

I have verified it using the approach you suggested and also double checked the code to make sure no duplicates.

I agree with you that it does not make sense this this the only case when invalid error is generated. But how to explain that "config false;" for the container prevents issue from happening. If duplicate subscriptions, wouldn't it still be observed then?

[jktjkt]

Sometimes the easiest option is just showing an example code that reproduces a weird issue; that's why I asked for how exactly your code makes the subscription(s).

[zdevcic]

After more checks and tests I came up with the conclusion that issue is caused by double subscription happening, but it was double subscription for config data (container global-vswr-thresholds), not for oper data (container using-vswr-thresholds) as sysrepo error suggests. After removing double config data subscription, oper data subscription is successful.

As earlier explained, really if we explicitly declare container using-vswr-thresholds as read-only ("config false;"), issue is not observed. Interesting and also a bit confusing/misguiding detail.

Not sure if you think there is more to investigate in the code, based on my summary. In any case I have no more queries and thank you for your support.

[michalvasko]

Could you please share the exact XPath you were subscribed to twice?

[zdevcic]

First subscription was towards regex:

/vendor-specific-thresholds:vswr-thresholds/global-vswr-thresholds

Then we had same subscription, but towards exact XPaths:

/vendor-specific-thresholds:vswr-thresholds/global-vswr-thresholds/vswr-major-threshold /vendor-specific-thresholds:vswr-thresholds/global-vswr-thresholds/vswr-critical-threshold

[michalvasko]

And you are talking about sr_module_change_subscribe(), right?

[zdevcic]

Will update once I have detailed info.