providerの適合試験は、host側の障害注入で書ける
providerを増やすことをモデルへの反例探しとして扱うなら、反例を偶然に任せず、決まった失敗シナリオを全providerに当てたい。providerを増やすのは対応範囲の拡大ではなく、モデルへの反例探しである
普通、こうした試験はprovider側でAPIクライアントをmockして書く。だがCarinaではproviderの外向きの通信はすべてhostを通る。だからhostの側で障害を注入すれば、providerの実装に手を入れずに同じシナリオを全providerに当てられる。「送ったかどうか」はproviderの申告ではなくhostが観測する
シナリオ
| 注入する障害 | 期待する分類 |
|---|---|
| 送信前に拒否する | NoResource |
| 送信後に応答を落とす | OutcomeUnknown(識別子やトークンを持っていればIdentifierReported / InFlight) |
| 送信後に期限を過ぎるまで遅らせる | 応答を落とした場合と同じ |
| createは通し、続く読み戻しを失敗させる | IdentifierReportedかPartialSuccess。NoResourceは誤り |
シナリオはcoreの型に対して一度だけ書き、providerは作成するリソースのfixtureだけを用意する。上流はローカルの偽サーバーか、記録した通信の再生にすれば、クラウドの認証情報も要らない。createの失敗は「外部世界について何が分かっているか」で分ける
既にあるもの、足りないもの
土台はある。hostの統合テストは、テスト専用のcarina-provider-mock-httpと、HTTPの宛先をローカルに差し替えるHttpTestRouteを使って「送信後にtrapすればoutcome_unknown」「送信前ならnot_created」を確かめている。carina-provider-mockにはCreateMode / ResumeModeで結果を指定する仕組みがある。
足りないのは、同じシナリオを実際のprovider(aws、awscc、github)に当てることである。今は、実providerが「応答が消えた」を正しい変種に落とすかは、実際のapplyで起きたときにしか分からない。
型が保証しないものを試験で埋める
型はproviderが書ける遷移を絞る。hostが送信を観測するので、「送っていないのにOutcomeUnknown」も書けない。だが「応答が消えたのに、providerが自分の判断でnot_createdを選ぶ」ことは型の上では書ける。送信が観測されていても、providerがクラウドの拒否を根拠にnot_createdを返すのは正当な経路だからである。この区別は型ではなく振る舞いの問題で、試験で押さえるしかない。Terraformはproviderに裁量を渡し、Carinaは型で取り上げる
根拠の確度
HttpTestRoute、carina-provider-mock-httpを使う統合テスト(initial_create_trap_after_dispatched_egress_is_outcome_unknownほか)、carina-provider-mockのCreateMode / ResumeModeはcarina main 273a2520で確認した。hostにfault injectionの仕組みが無いこと、似たissueが無いことは、コードとissueの検索で確認した(2026-11-06)。
送信が観測された後でもproviderがnot_createdを返せることは、統合テストprovider_declared_not_created_remains_not_created_after_egressで確認した。リクエストが実際にguestから出たことを確かめたうえで、providerが宣言したnot_createdがNoResourceのまま残ることを検査している。