If any schedule in a 'run after' daisy chain is Canceled, the subsequent schedule in the chain is not triggered - Known Error

If any schedule in a 'run after' daisy chain is Canceled, the subsequent schedule in the chain is not triggered Description This article describes an issue where canceling any schedule in a 'run after' daisy chain can prevent subsequent schedule from being triggered.

The behavior is caused by a race condition that may intermittently block further executions

Steps to Reproduce

The instance needs to be Zurich patch 7 or 8, or Australia patch 0 (EA1) or 1 (EA2) for this problem to apply.

Create multiple schedules and configure them in a 'run after' daisy chain (e.g., Schedule A → Schedule B → Schedule C). Ensure that each schedule is set to trigger the next one upon completion, by setting the next to 'run after' the previous. Ensure "even if canceled" is ticked on the schedules Start the first schedule in the chain (Schedule A). (you need to allow the scheduler to do that, as Discover Now won't cause run after sequences) While Schedule A is running or before it completes, cancel it. (this problem would also apply to schedules cancelled at max runtime, or due to inactivity) Observe the behavior of the subsequent schedules (Schedule B and Schedule C). Actual Behaviour:

In some cases, the subsequent schedule in the chain is not triggered after the first schedule is canceled, even when the “Even if canceled” field is set to true on the next schedule in the chain.

The discovery.canceled sysevent record is created, however that doesn't trigger the launch of the next schedule.

Expected behaviour:

For scheduled discovery schedules, where "even if canceled" is ticked, you would expect the schedules set to Run After to start when the previous schedule is canceled.

Workaround This problem has been fixed. If an upgrade is possible, please refer to the Fixed In section to determine the latest version with a permanent fix that the instance can be upgraded to.

For instances not yet on Zurich Patch 9 or Australia Patch 2 (GA), for a workaround apply the update set: Servicenow_PRB2005873_Workaround_sys_remote_update_set

This modifies a pair of Script Actions that are triggered by the discovery.complete and discovery.canceled system events:

Discovery Run Next: /sysevent_script_action.do?sys_id=c284ec4347022100fc856f2ccee490bf Discovery Run Next: /sysevent_script_action.do?sys_id=364ca80747022100fc856f2ccee490fb

Note: The sys_update_xml records are set as replace_on_upgrade=true so should not cause skipped upgrades in future. If you find this custom version is still in use after upgrading, you will need to Revert to the new system Version.