Terraformはproviderに裁量を渡し、Carinaは型で取り上げる
create失敗の後に何がstateに残るかを、誰が決めるか。ここでTerraformとCarinaは逆を向いている。
Terraform — providerがstateに何を書いたかで決まる
SDKv2では、d.SetId("…")を呼んだ時点でリソースはstateに入り、エラーを返してもそのまま残る。Plugin Frameworkではresp.Stateに書いたものが残り、エラーがあればtaintedになる。IDを書く前に失敗して早期returnすれば何も残らず、外部にできたリソースは管理外に落ちる。
Carina — providerが選べる遷移を型で絞る
providerは成功値を直接作れず、executorが渡した試行の証拠を消費して、許された遷移のどれかを選ぶしかない。「送ったかどうか」はhostが観測し、providerは申告できない。
Terraformの公式ドキュメントは"Any response errors will cause Terraform to mark the resource as tainted"と書く。つまり「作られたかもしれない」をstateに残すかどうかは、各providerの実装者が正しい順序でstateを書くかに懸かっている。コアはproviderの申告を信じるしかない。
Carina側の中身はcreateの失敗は「外部世界について何が分かっているか」で分けると「送ったかどうか」はproviderの申告ではなくhostが観測するに書いた。
| Terraform | Carina | |
|---|---|---|
| 失敗後のstate | providerが書いた分だけ残る | 失敗の種類ごとにコアが決める |
| 「送ったか」の根拠 | providerの実装次第 | hostの観測 |
| 成功値の作り方 | providerが組み立てて返す | 試行の証拠を消費してしか作れない |
| 正しさの担保 | provider実装者の規律 | 型(書けない遷移はコンパイルできない) |
代わりに払うもの
裁量を取り上げると、型が用意していない状況に出会ったとき逃げ場が無い。Terraformのproviderなら、サービス固有の妙な振る舞いもstateの書き方で吸収できる。Carinaでは、既存の型で表せるか、型を広げるか、provider内部に閉じるかを決めなければならない。この問いは対応サービスを増やすたびに起きる。providerを増やすのは対応範囲の拡大ではなく、モデルへの反例探しである。逃げ道の一般論は逃げ道の有無が表現力の上限と組織コストを交換するにある。
これは「呼び出し側が覚えていること」に依存する不変条件を型の形に作り直す、という原則(typestateで壊れた状態を書けなくする)をprovider境界に当てたものとも読める。SetIdの呼び順は、まさに「providerが覚えていること」である。
根拠の確度
Plugin Frameworkの引用は公式ドキュメントのCaveatsから写した。SDKv2でSetIdを呼べばエラーでもstateに入ることと、IDを書く前の失敗でリソースが管理外に落ちることは、terraform-plugin-framework#927の報告者の記述による。SDKv2のドキュメント本体では確認していない(要確認)。Carina側の事実は関連ノートを参照。「裁量」と「取り上げる」という対比の立て方は解釈である。