digdag（正確にはTreasureData Workflow）の sla パラメータで若干ハマったのでメモ。

slaとは

ドキュメントの通りですが、一定の時間を過ぎた場合、あるいは指定の時間を超えた場合にアラートを飛ばすことができます。

こちらもドキュメントに記載してありますが、 fail: オプションでworkflowを失敗にすることができます。

* sla: parameter supports duration: HH:MM:SS syntax in addition to time: HH:MM:SS syntax.
* sla: parameter supports fail: BOOLEAN and alert: BOOLEAN options. Setting fail: true makes the workflow failed. Setting alert: true sends an notification using above notification mechanism.

実際にやってみる

僕がハマりポイントがわかりやすいように実際に動かしてみます

以下のようなワークフローを定義します。
内容としては td_wait_table> でテーブルを待つだけです。
SLAは10秒に設定していて、fail: false としています。
手動でワークフローを実行後、10秒経過してから対象のテーブルを作成しました。

sample.dig

sla:
  duration: 00:00:10
  fail: false
  alert: false
  +notice:
    echo>: sla alert!!

+wait:
  td_wait_table>: tdwf_wait

_error:
  echo>: error!!

実行結果

10秒以上経過したため、 +notice で定義した内容が実行されてます。
SLAは超過していますが、テーブルが作成されたので正常に終了しています。

次に、fail: trueにして同じように実行してみます。

実行結果

同じく、10秒以上経過したため、 +notice で定義した内容が実行されています。
SLAは超過していますが、その後もタスクは実行され続け、テーブルを作成した時点でtd_wait_tableが正常終了で終わりますが、このタスク自体のステータスは失敗となります。
そのため、 _errorで定義した内容も実行されているのがわかります。

個人的に勘違いしていた点として、 fail: true にするとSLAを超えた時点で終了すると思っていましたが、そうではありません。

次にテーブルを作成せずに、途中でキャンセル（kill）してみます。
キャンセルはtd_wait_tableやs3_waitで24時間以上待っても存在しない場合に発生してしまいます

実行結果

タスクのステータス自体はキャンセルしているので、失敗となります。
ここで注目してほしいのでは _errorで定義した内容が実行されない ということです。

指定したSLAを超えた場合は+noticeで定義した内容を実行できますが、waitのタスクで24時間を超えても対象が存在しない場合は要注意です。

まとめ

fail: trueとしてもタスクが中断されるわけではない
waitのタスクで24時間超えた場合はキャンセルとなり、error処理が実行できない

fail: trueのユースケースってあるんだろうか。。

備考

TD workflow 0.9.13で実行