azdコマンドは前回のコマンド実行状態をローカルでキャッシュしている。

azd upもしくはazd down実行時には、前回までに実行したときのローカルキャッシュを元に実行するという動作になる。

このため、たとえば、azd upを実行してリソースを作成後、azdコマンド外（たとえばAzure Portal）でリソースを削除した場合、ローカルキャッシュではそれが保持されておらず、リソース作成済みという状態。

このとき、テンプレートも変更せずに、再度azd upでリソースを作成しようとするとどうなるか。

ローカルキャッシュもテンプレートも変更されていないため、変更なしと認識されてリソースの作成は実行されない。

sato@[10:03:26]:~/proj/RagSystem% azd up

Packaging services (azd package)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: xxx (xxx)
Location: East US 2

  (-) Skipped: Didn't find new changes.

ただし、私のazure.ymlファイルのpostprovisionは実行される。私の場合、作成したリソースめがけてロールの付与などを実施しているため、その処理だけは実行されるので軒並みエラー終了となるので、少々びっくりする。

sato@[10:03:26]:~/proj/RagSystem% azd up

Packaging services (azd package)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: xxx (xxx)
Location: East US 2

  (-) Skipped: Didn't find new changes.

ERROR: error executing step command 'provision': failed running post hooks: 'postprovision' hook failed with exit code: '1', Path: './infra/scripts/assignRolesToSystemOperator.sh'. : exit code: 1, stdout: System operators security group name is 'RagSystem-dev-operators'
... ＜エラー出力が続く＞

ならば、azd downを実行してからazd upを実行すれば良いのではと考えるのだが（通常であれば、azd up → azd down → azd upと実行すると、正しくリソースが生成・削除・生成と動作する）、azd down時には削除対象のリソースが存在しないため、azd down が失敗終了し、ローカルキャッシュはそのままという状態。

sato@[10:03:11]:~/proj/RagSystem% azd down

Deleting all resources and deployed code on Azure (azd down)
Local application code is not deleted when running 'azd down'.

ERROR: deleting infrastructure: error deleting Azure resources: no resources found for deployment, 'dev-1728693919'

これはどうやらazdコマンドのissue（考慮漏れ）のよう。

azd up / downを繰り返してもローカルキャッシュの状態が変更されないため、同じようにリソース作成はスキップされ、postprovisionで失敗するという状態になる。

Issue #2835で紹介されている方法で実行した結果、正常にリソース生成が実行された。

sato@[10:04:32]:~/proj/RagSystem% azd provision --no-state

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: xxx (xxx)
Location: East US 2

  You can view detailed progress in the Azure Portal:
  https://portal.azure.com/#view/HubsExtension/DeploymentDetailsBlade/~/overview/id/%2Fsubscriptions%2Fxxxf%2Fproviders%2FMicrosoft.Resources%2Fdeployments%2Fdev-1732928808

  (✓) Done: Resource group: RagSystem-dev (2.299s)
  (✓) Done: Virtual Network: RagSystem-MainVnet-dev (4.768s)
  (✓) Done: Key Vault: RagSystem-Kv-001-dev (4.973s)

SUCCESS: Your application was provisioned in Azure in 36 minutes 15 seconds.
sato@[10:44:20]:~/proj/RagSystem%

この—no-stateというフラグに関して、全く同じシチュエーションを想定した解説が2023年10月リリースノートに記載されていた。

Azure Developer CLI (azd) - October 2023 Release

以下、リリースノートに記載された—no-stateに関する記事の抜粋。

If you want to ignore the latest deployment state upstream, you can run azd provision --no-state to force azd to reprovision. You may want to pass the --no-state flag in if you’ve made changes to your infrastructure outside of azd (for example, in the Azure portal) and want to ensure that the values described in your Infrastructure as Code are applied.

この記事が2023年10月に記載されており、現時点（2024年11月）で同様の事象が発生するということは、この事象に対する対応方法があるため、この事象自体の対応優先度が下がったのか、そもそもこれをazdの仕様としたのかは不明。

この—no-stateというオプションは、ローカルキャッシュを利用せずにAzureリソースをプロビジョンする。

Azure Developer CLI リファレンス