要約

Automation for Jira (A4J) アプリで設定されたルールは、イベント (課題の作成、課題の更新、新しいコメントの追加など) によってトリガーされます。ルールが正しく機能していれば、アクションが実行されたかどうかにかかわらず、設定されているイベントをリッスンして、監査ログに新しいエントリが追加されます。ただし、状況によっては、自動化ルールで一部のイベントの “見逃し” や “スキップ” が発生する場合もあります。

この記事では、ルールが想定どおりにトリガーされない最も一般的な理由とその特定方法のリストを示します。

"ルールがトリガーされない" とは

まず、A4J の観点で "ルールがトリガーされない" とはどういう意味なのかを明確にしましょう。

• ここでは、新しい課題が作成されるとトリガーされるように A4J ルールが設定されていると仮定します。
• このルールが設定されたあとに、SCRUM-73 と SCRUM-74 というキーで課題が 2 つ作成されたとします。ルールの監査ログを確認した際に、課題 (下の例では課題キー SCRUM-73) のエントリが表示されていない場合は、この課題でルールがトリガーされなかったことを意味します。
  
  
  

特定のイベントが発生したときに自動化ルールがトリガーされるはずなのに、監査ログにエントリが記録されていない場合は、このナレッジ ベース記事に記載されている根本原因のいずれかが関与している可能性があります。

環境

• Jira Server/Data Center 8.0.0 以降
• Automation for Jira 7.3.0 以降

診断

どの根本原因が関係しているかを特定するには、次の点をチェックします。

• まず、トリガーされなかった自動化ルールが有効になっていることを確認します。下のスクリーンショットのように無効になっている場合は、根本原因 1 が関係しています。
  
• ([ルール詳細] ページで) 自動化ルールの [ルール トリガーを許可] オプションを探します。自動化ルールがトリガーされる頻度が低い場合、欠落したイベントが他の自動化ルールによって発生した場合は、根本原因 2 が関連します。
• 「課題の作成」イベントでルールがトリガーされるように設定している場合
  • 特定のプロジェクトや特定の課題タイプで作成された課題によってルールがトリガーされない場合は、根本原因 5 が関連している可能性があります。
  • CSV ファイルからインポートされた課題によってルールがトリガーされない場合は、根本原因 6 が関連している可能性があります。
• 影響を受ける自動化ルールの例の監査ログをご確認ください。自動化ルールがトリガーされても、そのルールで一部の課題が断続的にスキップされる場合は (以下の例のように)、根本原因 3 または根本原因 4 が関連している可能性があります。
  
• ⚙ > [アプリを管理] > [アプリを管理] ページから、Jira アプリで A4J が有効になっていることをご確認ください。 
  • Jira Data Center のクラスター ノードの場合、このアプリが特定のノードで無効になっている場合があるため、各 Jira ノードで A4J が有効になっているかを確認することが重要です。A4J が少なくとも 1 つのノードで無効になっている場合は、根本原因 3 が関連します。
  • A4J のステータスは次の方法で確認できます。
    • (ロード バランサーをバイパスして) 各ノードに直接ログインし、⚙ > [アプリを管理] > [アプリを管理] ページに移動します。 

    • または、各ノードからサポート zip を生成して、application.xml ファイルで「Automation for Jira」を検索します。ノードで A4J が無効になっていると、次のように表示されます。

          <plugin>
            <key>com.codebarrel.addons.automation</key>
            <name>Automation for Jira</name>
            <version>8.0.0</version>
            <vendor>Atlassian</vendor>
            <status>DISABLED</status>
            <vendor-url>https://atlassian.com/</vendor-url>
            <framework-version>2</framework-version>
            <bundled>User installed</bundled>
          </plugin>

• Jira クラスターのすべてのノードで A4J が有効になっていても、自動化ルールで一部の課題がランダムにスキップされている場合は、次のステップでスレッド ダンプを生成して自動化スレッドを検索します。少なくとも 1 ノードのスレッド ダンプでほとんどの A4J スレッドが見つからない場合、このノードは健全ではなく、根本原因 4 が関連します。
  
  
  
  • 単に比較する際は、Jira ノードが健全であれば、次のスレッドが見つかるはずです。
    
• When analyzing the thread dumps, if you find that all the A4J threads automation-rule-executor:thread-X are in the BLOCKED state (as shown in the example below) or in the TIMED_WAITING state, then Root Cause 7 might be relevant:
  
  

原因

根本原因 1 - ルールが無効になっている

ルールが無効になっていると、そのルールは設定されたイベントのリスニングを停止し、トリガーされなくなります。

Root Cause 2 - The allow rule trigger option is disabled

初期設定では、新しいルールの [ルール トリガーを許可] オプションが無効になっています。このような場合、ルールがリスニングしているイベントが別の自動化ルールの結果として発生すると、このルールはそのイベントを無視します。

他の自動化ルールによるこのルールのトリガーを許可するには、[ルール詳細] ページでこのオプションにチェックを入れる必要があります。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Automation for Jira - トリガーが別のルールから発生した場合にルールがトリガーされない」をご参照ください。

根本原因 3 - Jira Data Center クラスターの 1 つのノードで A4J アプリが無効になっている

Data Center 環境で Jira ノードのクラスターを使用している場合やノードが正常に起動しなかった場合は、その特定のノードで A4J アプリが無効になっている可能性があります。

この場合、次のようになります。

• そのノードで課題が作成/更新されるたびに、この課題によって発生したイベントは A4J に無視されます。該当のイベントはそのノードで無効になっているためです。
• よく見られる症状では、ほとんどの課題で自動化ルールがトリガーされても、課題がスキップされます。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Automation for Jira - アプリが無効化されているために一部の Jira 課題でルールがトリガーされない」をご参照ください。

根本原因 4 - A4J スレッドが Jira Data Center クラスターの 1 つのノードで実行されていない

Data Center 環境で Jira ノードのクラスターを使用している場合、A4J がすべてのノードで有効になっているのに、何らかの理由で、起動時にそれ自体のスレッドの初期化に失敗することがあります。A4J がそれ自体のスレッドの初期化に失敗する理由は不明ですが、まれなケースとして起こる可能性があります。

この場合、次のようになります。

• そのノードで課題が作成/更新されるたびに、この課題によって発生したイベントは A4J に無視されます。該当のイベントはそのノードで無効になっているためです。
• よく見られる症状では、ほとんどの課題で自動化ルールがトリガーされても、課題がスキップされます。

このシナリオとその解決状況に関する詳細については、ナレッジベース記事「Automation for Jira - スレッドが不足しているために一部の Jira 課題でルールがトリガーされない」をご参照ください。

根本原因 5 - 「課題の作成」イベントでルールがトリガーされるはずだが、ワークフローで間違ったイベントが発生する

新しい課題の作成時にトリガーされるルールは、Jira アプリによって発生する「課題の作成」イベントに依存します。初期設定では、どのワークフローも「課題の作成」イベントで開始されるように設定されます。そのため、このイベントに依存する機能 (Jira 通知、自動化ルールなど) をトリガーできます。

ワークフローの作成トランジションの事後操作が別のタイプのイベントを発生させるように編集された場合、このイベントに依存する自動化ルールはトリガーされなくなります。

ワークフローが課題作成時に正しいイベントを発生させているかどうかを確認する方法は次のとおりです。

• ルールがトリガーされると予想していた、作成された課題のタイプに関連するワークフローに移動します。
• [作成] トランジション > [事後操作] リンクの順にクリックします。
• 事後操作で発生するイベントをチェックして、次のいずれかであることをご確認ください。
  • ID 1 のイベント開始 (「課題の作成」イベント)
    
  • または「課題の作成」イベントを明示的に発生
    

根本原因 6 - ルールは「課題の作成」イベントでトリガーされるべきだが、課題が CSV インポートから作成された

Jira ですぐに使える CSV インポートには次の 2 タイプがあります。

1. 一括作成 ([課題] > [CSV からの課題のインポート] ページからアクセス可能)
2. CSV の外部システム インポート (⚙ > [システム] > [外部システム インポート] > [CSV] ページからアクセス可能)

1 番目のタイプのインポートは、課題を作成プロジェクト権限とプロジェクトの一括変更グローバル権限が付与されたユーザーが利用できますが、2 番目のタイプのインポートは Jira システム管理者ユーザーのみが使用できます。

注意すべき重要な点は、このインポートで課題が作成されたときに、2 番目のタイプのインポートでは「課題の作成」イベントがトリガーされないということです。その結果、トリガーされるこのイベントに依存する Jira (またはサードパーティのアドオン) 機能はトリガーされません。該当する機能には以下が含まれます。

• Jira のネイティブ Webhook
• Automation for Jira の「課題の作成」トリガー
• 「課題の作成」イベントに基づくメール通知

この挙動は、機能リクエストで追跡されます。「課題の作成」または「課題の更新」イベントは、CSV 外部システム インポートを使用して課題をインポートしてもトラップされません。

トリガーされなかった自動化ルールが「課題の作成」イベントで設定されている場合、および課題が CSV 外部システム インポートを使用して作成された場合は、この挙動は想定どおりであり、この根本原因が関連しています。インポートされた課題に対してルールが確実にトリガーされるように、一括作成 CSV インポートを代用する必要があります。

Root Cause 7 - All A4J execution threads are stuck due to a 3rd party add-on

The A4J execution threads automation-rule-executor:thread-X are responsible to process events that are accumulating in the A4J queue. We have seen a situation where all these threads might get into a "BLOCKED" or "TIMED_WAITING" state and stop running because of a 3rd party add-on.

To check if this root cause might be relevant, please refer to the KB article Automation for Jira - The automation executor threads are stuck because of the usage of a 3rd party add-on.

Root Cause 8 - Rules configured with the "Field value changed" trigger are not triggered due to the "Field Security Plugin for Jira" add-on

As explained in the KB article Automation For Jira - Some automation rules using the "Field value changed" trigger are not triggered, the 3rd party add-on Field Security Plugin for Jira might prevent automation rules using the Field value changed trigger from being triggered when the field they are monitoring is updated. To check if this root cause is relevant, please refer to the linked KB article.

Root Cause 9 - Rules configured with the "Multiple issue events" trigger are not triggered if the event was published by another rule

To verify if this root cause is relevant, check the following points:

• The only type of impacted rules are the ones configured with the Multiple issue events trigger
• The impacted rules are already configured with the Allow Trigger option ticked (allowing other rules to trigger these rules)
• The events that these rules should be triggered from are published by other automation rules
• The rules that are publishing the event do not have the option Publish newer style 'IssueEventBundle' ticked in the Publish Event action

If all the points above are verified, then this root cause is relevant, and we are facing the bug JIRAAUTOSERVER-910 - Getting issue details... STATUS

To fix this issue, tick the option Publish newer style 'IssueEventBundle' Publish Event action of all the rules that are publishing the events.

Root Cause 10 - Multiple rules are triggered by the same event and one of these rules is taking more than 5 minutes to complete

In the case where multiple rules are triggered by the same event, Automation For Jira loops over each rule 1 by 1 to process this event. If one of the rule that is processing the event takes more than 5 min to complete, the following happens:

• The event gets cleared from the cache (that's because Automation For Jira automatically clears events from the cache that have not been access for more than 5 min)

• The exception below is thrown in the Jira logs

  2023-11-07 09:59:18,905+0100 automation-rule-executor:thread-3 ERROR some_user     [c.c.j.p.a.service.execution.JiraThreadLocalExecutor] Unexpected error in thread local executor with actorKey 'some_user'.
  java.lang.IllegalStateException: There is no execution wih id=TenantExecution{tenantExecution=TenantExecution{tenantContext=TenantContext{environment=prod, clientKey='com.codebarrel.tenant.global', tenantId=TenantId{id='00000000-0000-0000-0000-000000bbbbbb'}}, executionUuid='c463420f-d3ae-41cb-9f4c-7d0122769999'}, auditItemId='10360381'}
  	at com.codebarrel.automation.api.execution.DefaultExecutionFinishSynchronizer.lambda$gerRuleInfo$2(DefaultExecutionFinishSynchronizer.java:108)

• Automation For Jira exits the loop even though there were still some rules left to process the event
• Ultimately, some rules miss the event and don't get triggered

This behavior was identified as a bug and reported in JIRAAUTOSERVER-946 - Getting issue details... STATUS

To verify if this this root cause is relevant:

• Check if the event that was missed by some automation rule(s) was processed by at least another automation rule that took more than 5 min to complete (automation rule execution times can be seen in the "Duration" column of the audit logs)
• Check if you can find the exception mentioned above in the Jira application logs

There is unfortunately no ideal/easy workaround for this bug, other than doing the following:

• Identify which rule is taking more than 5 min to process the event that was missed by other rules
• Then, either disable this rule, or optimize it so that it takes less than 5 min to complete

Root Cause 11 - The rule is configured using the trigger "Multiple issue events" and the wrong event was selected

If a rule is configured with the trigger "Multiple issue events", it is important to select the right event that this rule should be triggered on. For example, if this rule is configured to react to the event "Issue Updated", and you expect the rule to be trigger when an issue is transition to a new status, then the event figured by that transition needs to be the same event the rule is configured with.

To check if this root cause is relevant:

• Go to the Rule configuration and check which event is configured with the trigger "Multiple issue events"
• Go to the workflow used by the Jira issue that failed to trigger this rule, check the transition that was used for this Jira issue, and look at the list of post-function configured with this transition
• Look at the event that is fired by this transition
• If the event fired by the transition does not match the event the rule is listening, then this root cause is relevant
• In such case, either edit the workflow transition or the automation rule trigger so that both events match