Automation for Jira - All rules are failing to be executed due to the error "service proxy has been destroyed"
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Automation for Jira rules is failing to be executed due to the error "service proxy has been destroyed". When going to the Audit Logs of an example of impacted rule, we can see that the rule is triggered, but the status shows "FAILURE" with the error shown below:
1
2
Unexpected error executing rule:
org.eclipse.gemini.blueprint.service.importer.ServiceProxyDestroyedException: service proxy has been destroyed
Diagnosis
When checking the Jira application logs, the following error can be found:
1
2
3
4
5
6
7
8
9
10
11
2022-09-20 00:33:56,954-0700 automation-rule-executor:thread-3 ERROR someuser [c.c.a.api.service.ComponentChainImpl] Unexpected runtime error executing component for config 'XXXXXXX':
com.atlassian.util.concurrent.LazyReference$InitializationException: org.eclipse.gemini.blueprint.service.importer.ServiceProxyDestroyedException: service proxy has been destroyed
at com.atlassian.util.concurrent.LazyReference.getInterruptibly(LazyReference.java:149)
at com.atlassian.util.concurrent.LazyReference.get(LazyReference.java:112)
at com.atlassian.util.concurrent.ResettableLazyReference.get(ResettableLazyReference.java:92)
at com.codebarrel.jira.plugin.automation.template.JiraTemplateRendererContextProviderFactory.getContextProviders(JiraTemplateRendererContextProviderFactory.java:98)
at com.codebarrel.automation.rulecomponent.jira.common.renderer.IssueInputSubstitutionRenderer.compile(IssueInputSubstitutionRenderer.java:153)
at com.codebarrel.automation.rulecomponent.jira.condition.jql.JqlCondition.executeWithIssues(JqlCondition.java:59)
at com.codebarrel.automation.api.component.executor.IssueRequiredExecutor.execute(IssueRequiredExecutor.java:34)
at com.codebarrel.automation.api.component.executor.IssueRequiredExecutor.execute(IssueRequiredExecutor.java:17)
at com.codebarrel.automation.api.component.branch.condition.IfBlock.lambda$matchCondition$1(IfBlock.java:53)Cause
While the exact root cause of this issue is not entirely clear, we observed that it usually occurs if Automation for Jira (A4J) is disabled and then re-enabled after the add-on ScriptRunner is installed. We suspect that there might be some issue with the way add-ons that contain A4J extensions load these extensions, ultimately bringing A4J into an unstable state.
Note that ScriptRunner is only one example of such an add-on, but there could be other add-ons that also come with A4J extensions and might trigger the issue.
The ScriptRunner team is currently investigating this issue in this public bug ticket: https://productsupport.adaptavist.com/browse/SRJIRA-6234
We found that following the steps below is 1 way of replicating the failure of A4J rule executions:
Install Jira Server/Data Center on any 9.3.0 version (which is bundled with A4J 8.0.3)
Install ScriptRunner on the latest version via the page ⚙ > Manage Apps > Find new Apps
Create a Jira Software project, and configure in the project an automation rule (via
Project Settings > Project Automation) that is triggered on the issue created event
Create a new issue to trigger the automation rule
Check the audit logs of that rule
It should execute successfully
Go the page ⚙ > Manage Apps > Manage Apps, disable and re-enable A4J
Create any Jira issue to trigger the automation rule test created earlier.
Create a new Jira issue to trigger the automation rule
Check the audit logs of the rule created earlier
It will fail with the error "service proxy has been destroyed"
Solution
There are various ways to fix this issue and bring A4J back into a stable state. For either method, please make sure to schedule a maintenance window to prevent any impact on daily operations.
Solution 1: Perform a rolling start of all the Jira nodes (or simply restart the Jira application in case of a single node environment)
Solution 2: disable and re-enable the A4J add-on from the page ⚙ > Manage Apps > Manage Apps
Was this helpful?