Tested scenario 1 with confd device.

Attached request details and confd logs for reference.

Sarguna_Dharani, do you have the body you are using to mount this device?

Also, I saw you assigned this to yourself. Do you have plans to fix?

Let me know how I can help.

Hi jluhrsen,

Thanks for the reply. Yes, I have committed the fix for it.

And I have used below payload for mounting confd device,

<node xmlns="urn:TBD:params:xml:ns:yang:network-topology">
<node-id>confd-netconf-device</node-id>
<host xmlns="urn:opendaylight:netconf-node-topology">XXX.XX.XX.XX</host>
<port xmlns="urn:opendaylight:netconf-node-topology">2022</port>
<username xmlns="urn:opendaylight:netconf-node-topology">admin</username>
<password xmlns="urn:opendaylight:netconf-node-topology">root</password>
<tcp-only xmlns="urn:opendaylight:netconf-node-topology">false</tcp-only>
</node>

Hi Sarguna_Dharani, I also commented in the gerrit but wondering if you had the bandwidth to add unit test coverage for these cases?

Sarguna, I pulled your code locally and built it to test. I have a Junos device that is only :candidate and I still see the
problem I think is reported here.

two curl commands back to back to delete an existing interface (small 3s sleep between to make reading the logs easier).
I see the first request grab the lock, get-config, edit-config, commit, unlock... Somewhere before the unlock the 2nd
request tries to get the lock and it fails, but things just continue the same with that request... get-config, edit-config,
commit, unlock.

Am I following this correctly? Should the 2nd request get the lock denied and just quit at that point responding to the
calling client about the error? Is that what you see with your confd environment?

Hi Jamo,

Can you please check whether you get lock-denied for the 2nd request from the device

When I tested this case, testtool doesn't give rpc-reply as lock-denied for the 2nd request

You can check this by executing 2 lock request simultaneously

http://localhost:8181/restconf/operations/network-topology:network-topology/topology/topology-netconf/node/<device-name>/yang-ext:mount/ietf-netconf:lock

If device accepts the second lock , then definitely it will continues with other transaction.

If device denies the second lock , it should immediately stop and respond error to calling client.

If lock has been denied in your testing for second request , can you please include netconf and device logs here  

Hi Jamo,

I found the issue. The thing is DELETE works in different way , it uses "exists" functionality of MDSAL to trigger get-config transactions.

But PUT calls uses "read" functionality of MDSAL to trigger get-config transactions.

Only in read calls , there is check for lock transactions

I am adding the fix for it.

great! thanks Sarguna

I'll work to get these scenarios covered in CSIT as well. Not sure how easy
the UT would be, but maybe CSIT will be enough to help catch regressions.

cmanojwill take a look at doing this CSIT

Hi Sarguna, wondering if you have any update on this?

Hi Jamo, 

Included changes for both Delete calls and Unit Testing. 

Thank you Sarguna_Dharani I've tested locally with the distribution built from your patch and
things seem to work as expected.

So reading through this a bit more, the RESTCONF seems to be okay – we can improve it by adding a dedicated case. The problem is what sal-netconf-connector does, which is that it plows on even in case of rejection. I think the patch is going to be more involved.

Hi jluhrsen
Is there any CSIT already covers these scenarios?
Have prepared changes for it. And I am wondering how I can properly test it

no, I don't think any CSIT was written for this yet unfortunately. I had intended to come up with something eventually but
I no longer have the cycles for it.

Hi Sarguna and jluhrsen,

I've changed the design slightly; it should only execute operations from the transaction if the lock operation is completed successfully. I noticed a couple of other issues during testing, like an unexpected lock/unlock state that happened because of parallel transactions, so I had to fix that as well.

The patch is available here - https://git.opendaylight.org/gerrit/c/netconf/+/95359; for some reason, JIRA associates my patch with a different issue