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


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:

Service proxy destroyed exception in automation
1 2 Unexpected error executing rule: org.eclipse.gemini.blueprint.service.importer.ServiceProxyDestroyedException: service proxy has been destroyed


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( at com.atlassian.util.concurrent.LazyReference.get( at com.atlassian.util.concurrent.ResettableLazyReference.get( at com.codebarrel.jira.plugin.automation.template.JiraTemplateRendererContextProviderFactory.getContextProviders( at com.codebarrel.automation.rulecomponent.jira.common.renderer.IssueInputSubstitutionRenderer.compile( at com.codebarrel.automation.rulecomponent.jira.condition.jql.JqlCondition.executeWithIssues( at com.codebarrel.automation.api.component.executor.IssueRequiredExecutor.execute( at com.codebarrel.automation.api.component.executor.IssueRequiredExecutor.execute( at com.codebarrel.automation.api.component.branch.condition.IfBlock.lambda$matchCondition$1(


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:

We found that following the steps below is 1 way of replicating the failure of A4J rule executions:

  1. Install Jira Server/Data Center on any 9.3.0 version (which is bundled with A4J 8.0.3)

  2. Install ScriptRunner on the latest version via the page ⚙ > Manage Apps > Find new Apps

  3. 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

  4. Create a new issue to trigger the automation rule

    • Check the audit logs of that rule

    • It should execute successfully

  5. Go the page ⚙ > Manage Apps > Manage Apps, disable and re-enable A4J

  6. Create any Jira issue to trigger the automation rule test created earlier.

  7. 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"


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

Updated on June 7, 2024

Still need help?

The Atlassian Community is here for you.