Duplicate task_sla Records on Security Incident Tasks: Root Cause and Resolution

[sarah_bioni]

Summary

Security Incident (sn_si_incident) tasks may receive two task_sla records for the same SLA definition, even though the task history shows the SLA was moved to Draft only once. The two records are created a few seconds apart.

Symptoms

• Two task_sla records for the same SLA definition on one Security Incident task.
• The task’s audit history shows only one transition to Draft.
• Start conditions match on both records.
• The SLADataCollector script reports inconsistencies in the update numbers of the task’s audit history.

 

Root Cause

The audit history for the affected task is corrupted because of split transactions. All updates that share one update number should have the same timestamp and the same internal checkpoint. When they differ, the update was split across transactions. The SLA engine then processes the task from stale data in the current GlideRecord, and attaches the SLA a second time.

Resolution

Step 1: Set the system properties

1. Confirm that the system property com.snc.walker.default is set to CHECKPOINT.
2. Update the system property com.snc.sla.get_task_from_db to include the SIR task table. For example, if the current value is sc_req_item, set it to sc_req_item,sn_si_incident.

With this setting, the SLA engine fetches each listed task record from the database instead of using the current GlideRecord. This prevents SLAs from being processed with stale data.

Step 3: Repair the affected tasks

1. Open each affected task.
2. Click Repair SLA. This action is restricted to administrators.
3. Confirm that only one task_sla record remains for the SLA definition.

Considerations

• Test the property change in a sub-production instance before you apply it to production.
• Run Repair SLA only on tasks that show duplicates, and only with administrator access.