Provision status should not change if no config change on device with transactional commit failure: Steps:1. Edit an L2VPN service by changing locator name to be an invalid one (with space in the string) from Service Manager2. From Commit manager -> Click Commit -> Yes CommitAn Error repot pops up as expected (screenshot attached)3. Click "Close"4. Now the Plan showed failed from Configuration Editor.The configuration on device has no change due to this failure. Should the provision status remain the same as before commit because this commit is in transactional mode.The confusing part presents on CNC UI, is after users see this error message. User select Cancel -> Leave. And see the provisioning state as "Failed". But in fact there is no changes on the device. 
playload attached. Hi Crystal,There has been much debate with the NSO platform team about whether no-CQ service failures should result in plan showing failed state. You can read more about the discussion here : To summarize, the conclusion was that the platform team determined that plan should show failed status when no-CQ transaction fails and is aborted, even if there is no southbound change.The behavior you have described is expected in accordance to behavior defined by NSO platform team. To recover your service state, you can follow our error recovery procedure : For your case, because nothing was pushed southbound (and assuming there was no out of band changes), to fix service plan state, simply re-deploy the service.Please let me know if you have any additional questions.Thanks,Isaac KimHi Isaac, don't have access to .  Could you include the transcripts of that ticket here?Hi Srinivasan,There doesnt seem to be a way to post the entire transcript, but here is a snippet from the platform team describing the behavior mentioned above:I would say that this works as expected since the failed leaf has the following description: <tt>This leaf is present if any plan component in the plan is in a failed state; i.e., a state with status 'failed', or if the service failed to push its changes to the network.</tt> <tt>I think the reasoning behind setting the failed leaf even for a non-CQ commit is that we want it to behave the same way in both cases. And as the description of the failed leaf says the push of changes to the network has failed in both cases, so it should be set in both cases.</tt> <tt>It is worth noting that the failed leaf can also be set by the side effect queue if a side effect fails for some reason. So even if we would not set the failed leaf for non-CQ commits if might happen that the side-effect queue will set the failed leaf.</tt>Thanks,Isaac KimHi,Please let me know if the error recovery procedure that was recommended fixed the plan state.Thanks,Isaac KimExpected behavior according to NSO platform team.