Issue Summary

There might be occurrences on a production environment that may forcefully terminate the execution of Automation rules, such as when the Jira process is forcefully terminated.

Those rules execution may still be reported as in progress despite not being running anymore.
This affects the audit logs and performance insight.

Steps to Reproduce

1. Install a vanilla instance of Jira Data Center and make sure Automation for Jira is on the latest version available.
   • This was validated on Jira Software DC 9.2.0 (Automation for Jira 8.0.4).
2. Create a sample project.
3. Create a global rule with the following:
   • Trigger: Issue created.
   • Action: Add comment.
4. Create an issue and ensure the rule runs properly.
   
5. Attach a debugger to the Jira process and create a break point in com.codebarrel.automation.rulecomponent.jira.action.comment.executeWithIssues.
   
   • This is to make the bug easily recreated, but may not be the only way to trigger it in a production environment.
6. Create a new issue so the rule is executed with the break point enabled.
7. Forcefully kill Jira's JVM process while the rule was in progress.
   • Note the in progress rows in AO_589059_AUDIT_ITEM and AO_589059_RULE_STAT database tables.
8. Start Jira and let it run for some minutes/hours.
9. Check the rule audit log and performance insight.

Expected Results

Automation for Jira should have a way to identify a rule reported as in progress isn't really running anymore and update it in the audit and insight related tables.
The rule execution that was in progress while Jira went down has a status of failure or some errors.

Actual Results

The rule execution that was in progress while Jira went down is still reporting a status of in progress and will continue to be until the audit log expiration job runs and captures this entry (only when it expires by its timestamp).

The specific rule execution will still be reported as in progress in the Automation Performance Insight tables and the execution will never appear in the Insight UI.

Workaround

You may determine an interval on which a rule should not be executing anymore. For this example we will set 2 hours as the limit, but that will certainly be different on your instance and should be determined by the Jira administrator.
With that you can periodically run queries to update the status directly in some database tables.

1. Identify affected entries related to the audit log.
   PostgreSQL

   select ai.*
   from "AO_589059_AUDIT_ITEM" ai
   where ai."CATEGORY" = 'IN_PROGRESS'
   and ai."CREATED" < NOW() - INTERVAL '2 hours'
   

   SQL Server

   SELECT *
   FROM [dbo].[AO_589059_AUDIT_ITEM]
   WHERE [CATEGORY] = 'IN_PROGRESS'
   AND [CREATED] < dateadd(hour, -2, getdate());
   

2. Update rows in the audit log table.
   PostgreSQL

   update "AO_589059_AUDIT_ITEM"
   set "CATEGORY" = 'SOME_ERRORS'
   where "CATEGORY" = 'IN_PROGRESS'
   and "CREATED" < NOW() - INTERVAL '2 hours'
   

   SQL Server

   UPDATE [dbo].[AO_589059_AUDIT_ITEM]
   SET [CATEGORY] = 'SOME_ERRORS'
   WHERE [CATEGORY] = 'IN_PROGRESS'
   AND [CREATED] < dateadd(hour, -2, getdate());
   

3. Identify affected entries related to performance insight.
   PostgreSQL

   ------- AO_589059_RULE_STAT
   select rs.*
   from "AO_589059_RULE_STAT" rs
   where rs."CATEGORY" = 'IN_PROGRESS'
   and rs."CREATED" < NOW() - INTERVAL '2 hours'
   

   SQL Server

   SELECT *
   FROM [dbo].[AO_589059_RULE_STAT]
   WHERE [CATEGORY] = 'IN_PROGRESS'
   AND [CREATED] < dateadd(hour, -2, getdate());
   

4. Update rows in the performance insight table.
   PostgreSQL

   ------- AO_589059_RULE_STAT
   update "AO_589059_RULE_STAT"
   set "CATEGORY" = 'SOME_ERRORS'
   where "CATEGORY" = 'IN_PROGRESS'
   and "CREATED" < NOW() - INTERVAL '2 hours'
   

   SQL Server

   UPDATE [dbo].[AO_589059_RULE_STAT]
   SET [CATEGORY] = 'SOME_ERRORS'
   WHERE [CATEGORY] = 'IN_PROGRESS'
   AND [CREATED] < dateadd(hour, -2, getdate());