競合エラーをデバッグする

このページでは、競合エラーの一般的な原因と、ワークフローで競合による失敗を減らす方法について説明します。

一般的な原因

別のアクションが同じオブジェクトを編集する

アクションの実行中に別のアクションが同じオブジェクトを変更すると、Actions:ConcurrentModification または Actions:ObjectVersionChanged でアクションが失敗することがあります。スナップショット分離モードでは、別のアクションによる変更が上書きされないように、プラットフォームが編集を拒否します。これは、アクションが異なるプロパティを編集する場合にも当てはまります。

例： priority と assignee の2個のプロパティを持つ Ticket オブジェクトタイプがあるとします。同じチケットに対して、どちらもスナップショット分離を使用する2個のアクションを同時に実行します。

• アクション A は priority を Low から High に変更します。
• アクション B は assignee を Alex から Sam に変更します。

アクション A が先にコミットします。その後、アクション B は、チケットが変更されたため競合チェックに失敗します。アクション A が変更したのが別のプロパティであっても同様です。

これらの競合を解消するには、次の方法を使用します。

• アクションの自動再試行を設定します。
• 同じオブジェクトを編集するアクションを連携させるようにワークフローをリファクタリングします。
• これらの変更ができない場合は、Read Committed 分離モードの使用を検討します。

元データソースが更新される

アクションの実行中にオブジェクトタイプの元データソースが更新されると、Actions:ObjectVersionChanged でアクションが失敗することがあります。競合チェックでは、オブジェクトタイプ全体のデータソースの更新を追跡します。更新されたデータソースの行が、アクションで編集するオブジェクトに対応していない場合でも、アクションが失敗することがあります。

例： スナップショット分離を使用するアクションが、チケット A の assignee を変更しようとします。その実行中に、データソースの更新によってチケット B と C の priority が変更されます。チケット A の値が変更されていなくても、チケット A を編集するアクションが失敗することがあります。

これらの失敗を解消するには、次の方法を使用します。

• アクションの自動再試行を設定します。
• 可能な場合は、データソースの更新を待ってからアクションを実行するようにワークフローをリファクタリングするか、データソースの更新頻度を下げます。
• これらの変更ができない場合は、Read Committed 分離モードの使用を検討します。

オブジェクトデータベースがメンテナンスを実行する

オブジェクトデータベースは、効率的な動作を維持するために定期的にメンテナンスを実行します。編集が多いオブジェクトタイプでは、このメンテナンスの実行頻度が高くなることがあります。このメンテナンス中に実行されるアクションは、Actions:ConcurrentObjectTypeModification または Actions:ObjectVersionChanged で失敗することがあります。

メンテナンスは、元データソースを持たないオブジェクトタイプにも影響することがあります。

アクションの自動再試行を設定します。メンテナンスの完了後は、再試行が成功するはずです。自動再試行後もこれらの失敗が続く場合は、Palantir サポートにお問い合わせください。

アクションの自動再試行を設定する

アクションタイプで再試行を有効にする

Ontology Manager で、アクションタイプの機能タブを開き、一時的なエラー時の再試行モードで設定を選択します。選択肢は次のとおりです。

• 外部呼び出しのないアクションのみ（デフォルト）： 外部システムを呼び出さないアクションのみを再試行します。
• すべてのアクション： すべてのアクションを再試行します。
• 無効： 最初の失敗を呼び出し元に返します。

プラットフォームは、読み取り専用のリクエストであっても、OSDK アクセスを外部呼び出しとして分類します。そのため、OSDK を使用する TypeScript v2 および Python の関数ベースのアクションは、デフォルトでは再試行されません。これらのアクションで競合エラーが発生する場合は、すべてのアクションの選択を検討します。

アクションが、安全に繰り返せない可能性がある（冪等ではない）外部呼び出しを行う場合は、すべてのアクションを選択しないでください。たとえば、オントロジーを編集する別のアクションを呼び出す Webhook を再試行すると、編集が重複する可能性があります。

再試行の動作については、詳しくはこちらをご覧ください。

再試行が有効な場合、プラットフォームはアクションの実行を最大5回試みます。競合が続く場合は、上記の一般的な原因に関するガイダンスに従います。Automate または API クライアントで再試行回数を増やしても、原因が解消されないまま、遅延やシステムの負荷が増加する可能性があります。

同じオブジェクトへの更新を調整する

Workshop、OSDK、Actions API、Automate から実行されるアクションを含め、ワークフローで同じオブジェクトを編集するすべての方法を特定します。これらのクライアントから実行されるアクションは、互いに競合する可能性があります。

エラーの詳細を確認する

Workshop を使用している場合は、アクションの失敗後に表示されるエラートーストを確認します。エラー名でエラーを特定でき、オブジェクトの詳細は影響を受けるオブジェクトを見つけるのに役立ちます。

Automate を使用している場合は、自動化の履歴タブを開き、失敗したイベントを選択してから、アクションの効果を選択して実行の詳細を表示します。トレースでは、失敗したアクション実行が示されます。

詳細ビューで、失敗したログエントリのコンテンツフィールドを選択して、ログの詳細を開きます。この例では、Actions:ObjectVersionChanged と HTTP ステータス 409 が表示されています。

OSDK アプリケーションを開発している場合や Actions API を呼び出している場合は、アクションリクエストによって返されたエラーを確認します。この例では、API が ObjectChanged をエラーコード CONFLICT、HTTP ステータス 409 とともに返しています。

競合の原因を調査する

Ontology Manager で、オブジェクトタイプのデータソースタブにあるユーザー編集履歴を追跡を有効にします。Workshop または Object View で編集履歴ウィジェットを使用して、失敗したアクションの実行中に同じオブジェクトに対して行われた編集を確認します。これにより、競合の原因となった、成功したアクション実行を特定できます。異なるプロパティへの編集でも競合が発生する可能性があるため、すべてのプロパティを表示します。

編集履歴には、有効にした後に行われた編集が記録されます。元データソースの更新は含まれません。

同じオブジェクトに対するアクションを1つずつ実行する

OSDK アプリケーションを開発している場合や Actions API を直接呼び出している場合は、同じオブジェクトを編集する各アクションが完了するのを待ってから、次のアクションを実行します。

Automate を使用している場合は、アクションが重複する箇所に応じた設定を選択します。

• 1つのイベント内に複数の効果がある場合： 各アクションを個別の効果に配置し、効果を順番に実行します。1つの効果の設定済みアクションに複数のアクションを追加しても、実行順序は保証されません。
• 1つの自動化から複数のイベントが発生する場合：****条件ページで詳細設定を展開し、キュー効果の実行を有効にします。各イベントは、前のイベントが完了するまで待機します。イベント内の効果が同じオブジェクトを編集する場合は、効果を順番に実行する設定も行います。
• 1つのワークフローに2つの自動化がある場合：自動化の依存関係を設定して、最初の自動化が完了した後に2つ目の自動化をトリガーします。

同じオブジェクトを更新するアクションをまとめる

ワークフロー内の複数のアクションが同じオブジェクトを編集する場合は、それらを1つのアクションにまとめることを検討します。まとめたアクションが自身の編集内容を読み取る必要がある場合は、ステージング書き込みを使用します。

たとえば、あるプロジェクトに status が Open に設定された3件のタスクがあるとします。ワークフローでは、タスクごとに1つのアクションを実行して、そのタスクを Completed に設定し、プロジェクトの completedTaskCount を更新します。3つのアクションすべてが同じプロジェクトを共有して編集するため、競合する可能性があります。

これらを、ステージング書き込みを使用する1つの関数ベースのアクションにまとめ、次の処理を行います。

1. 3件のタスクすべてを Completed に設定します。
2. プロジェクト内で完了しているタスクの数をクエリします。
3. プロジェクトの completedTaskCount をステップ2の結果に設定します。このアクションはステージング書き込みを使用するため、クエリにはステップ1で設定した3件のタスクが含まれ、件数は 3 になります。

競合の原因となるパターンを避ける

ワークフローに次のパターンがないか確認します。

• 同じオブジェクトを編集するアクションを同時に実行しないでください。 異なるプロパティを変更する場合や、異なるアプリケーションから実行される場合でも、競合する可能性があります。1つずつ実行するか、1つのアクションにまとめます。
• オブジェクトタイプの元データソースの更新中にアクションを実行しないでください。 可能な場合は、それらの更新が完了するのを待ってからアクションを実行するか、データソースの更新頻度を減らします。