Thousands of Stale CIs but no Stale CI Remediation Tasks

[Phil32]

We are newly trying to set up our CMDB dashboard and remediation rules.  Starting with the Staleness metric for a single class to test, as we know it will need to delete over 400,000 stale CIs.

The job came back with what looks like a list of Stale CIs, but doesn't generate a STAL task

The really weird part is, the Last Evaluated On date is from the previous week

[Bob D]

Jake - thank you for your response.  However, it doesn't look as if this helped.  I changed the workflow conditions as described in the KB article (changed "If condition matches" from "Run the workflow always" to "None"  and re-published the workflow).  But the STALxxxxx tasks still ran automatically.

[yandewulf]

We are experiencing the same. Our staleness remediation tasks are running automatically even though the stale remediation rule is set to manual. We are running Kingston.  

[Jake Armstrong]

Could you check KB0687097 and see if it applies?

[yandewulf]

Thank you Jake. Yes it does. Changing the workflow's property condition from "Run the workflow always" to "None" stopped the remediation task from deleting all CIs marked stale no matter if the rule was set to manual and no matter what CI class they were in. 

[yandewulf]

NOTE:  There are 2 source of stale CIs, the 1st comes from CI staleness rule(s) applied by the =correctness job= (part of the health metrics) and the 2nd one comes from "Cloud" discovery, as in setting up AWS or other Cloud discovery schedules.  This 2nd source results in stale CI remediation with a description of "Cannot find CI from cloud provider's API". Cloud resources (including vCenter CIs) do not use CI staleness rules because ServiceNow uses the targeted cloud as THE source of truth. When scanning for regular CI's (non-cloud resources) there are many reasons discovery can fail,  hence 1st needing to define staleness rules, like if device was not discovered for more than 60 days, mark it as stale. The same is not true with cloud CIs. When discovering the cloud when a CI that was previously discovered is no longer found then ServiceNow marks it as stale. Previously ServiceNow "orphaned" these records, deleting all relationships to other resources but starting with Jakarta, ServiceNow now marks these Cloud CI records as stale.

This logic is from a java class called "SNC.DiscoveryCIReconciler.updateStaleness()" , and is called by the a script includes called scriptLIKEDiscoveryCIReconciler.updateStaleness.

NOTE there is PRB1267732 that will be fixed in Kingston Patch 10 and London Patch 2. This PRB is to stop stale "Cloud" CIs from creating a Stale CI remediation task. The work around for now, add a business rule that  should be on insert, and the condition should be "source" is "Cloud Discovery". You must check the "Abort action" field under Actions tab, it will  prevent records from getting inserted to the stale_ci_remediation table to abort task creation when description matched "Cannot find CI from cloud provider's API".