Digdag / TreasureData Workflowのエラー処理

Mon, 14 Sep 2020 00:00:00 +0900

この記事はDigdag v0.9.41時点の検証結果に基づく。

Digdag / TreasureData Workflowのエラー処理。エラー時の処理を指定する_errorだけでなく_checkやfail>:などの処理もあり、エラー発生／成功時の処理をカスタマイズできる。自由度が高く、ワークフローの階層構造とともにうまく使えばワークフローのコードが簡潔になる。公式ドキュメントの説明が不十分なので補足する。

Digdagがエラーと判定して`_error`を発動する条件

コマンドの戻り値が0であれば正常、0でなければエラーとみなす。つまりシェルスクリプト（sh:>）の場合は

exit 1

であればエラーとなる。

`_error`を複数の階層で記述するとどうなるか

_errorは同一階層には複数記述できないが、異なる階層には記述できる。以下のようにワークフローを設定する。 test.dig

+task1:
 +task2:
 sh>: exit 1
 _error:
 echo>: Task 2 failed.
 _error:
 echo>: Task 1 failed.
_error:
 echo>: Top failed.

最上位階層にTop failed.を表示する_error
第2階層（task1の階層）にTask 1 failed.を表示する_error
第3階層（task2の階層）にTask 2 failed.を表示する_error

があり、第3階層でエラーを発生させる。

ubuntu@c0591acea4ab:~/digdag/wf_cdp$ digdag run -a -L test.log test.dig
2020-09-13 23:17:39 +0900: Digdag v0.9.41
Task 2 failed.
Task 1 failed.
Top failed.
error:
 * +test+task1+task2:
 Command failed with code 1 (runtime)

Task state is saved at /home/ubuntu/digdag/wf_cdp/.digdag/status/20200912T000000+0000 directory.
 * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
 * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

第3階層→第2階層→最上位階層と順に動作する。エラー処理を記述した階層だけでなく、上位階層に伝播する。エラーはまとめてSlackに通知したいが細かい処理はワークフローによって分けたい場合などはこの挙動を踏まえておくといい。

ワークフロー on Marketechlabo

Digdag / TreasureData Workflowのエラー処理

Digdagがエラーと判定して_errorを発動する条件

_errorを複数の階層で記述するとどうなるか

Digdagがエラーと判定して`_error`を発動する条件

`_error`を複数の階層で記述するとどうなるか