Duplicate SLA generation caused by a scheduled job update on IncidentIssue SLA retriggered on Incident (created a duplicate SLA definition) after an update by scheduled job even though the start condition of the SLA definition no longer met as state of the incident no longer NEW.CauseA race condition between different application nodes updating to the same incident. The scheduled script read the incident from the Database where the incident state was 1 and then the user updated the state to 3 and then the scheduled job wrote to the database, giving the SLA Engine its version of current (which still has state value 1) while DB has value 3.ResolutionThere are two ways to solve this particular issue. 1. setWorkflow false on the scheduled job script so that it does not run the SLA Engine. (SetWorkflow(false);) Pros: solve current issue Cons: will not trigger BRs/Workflows or entries in audit history 2. Add incident to property: com.snc.sla.get_task_from_dbThis property value does as following. When processing SLAs any of the Task tables specified in this property, the "current" GlideRecord object will not be used. Instead, the record will be fetched from the database. This can be used to prevent SLAs from being processed with stale data in "current". Pros: should fix/prevent this issue Cons: slows SLA Engine processing (because every incident processed is re-queried).