Service Sync-to and Sync-from actions: Trying to understand when and how to use service Sync-to and Sync-from actionScenario:1. Make headend router OOS (out of sync)2. Provision a policy with async commit queue  The provision in provisioning failed state as expected3. Do a device sync-to or sync-from to make device in sync4. Do a service "Sync to"The policy is still in provisioning failed state. Is this expected? service sync-from has the same result.Can you clarify what is the use case for service/policy sync-to and sync-from actions?
Hi Crystal,Please follow the error recovery procedures: The issue that you're facing is expected, since the T-SDN service was not re-deployedHi Reginald,I am a bit confused. I tried the similar steps as the original one except put the device OOS, I made it unreachable. The service Sync-from or Sync-to make the service becomes provisioning successful state.In both scenarios are error-recovery with different sync directions. No re-deploy were done for either one. But with different result. Can you let me know why the results are different for these 2 scenarios? Are both expected results?New Scenario:1. Make headend node reachable2. Provision a policy with async commit queueThe provision in provisioning failed state as expected3. Make headend node reachable4. Do a service "Sync from" or "Sync to"First let me confirm, I maybe missing something important but what do you mean by "service sync-from/sync-to" are you referring to the error-recovery action itself and passing sync-from/sync-to direction? Also for the new scenario, you made "headend node reachable" but you didn't do this for the first scenario? If you outline the reproduction steps with the payloads/actions in question I can probably give you a clearer answerSubmitter was trying to use error-recovery action for persistent failure for the first scenario which is not supported. Using the flow outlined in our we were able to resolve the issue.We did find a bug with the error-recovery action throwing an error, but also returning a "Recovery Complete" which is probably what was confusing. The submitter will file a CDETs for this.