409 エラーの記事一覧

冒頭まとめ Kubernetes の 409 Conflict は、1つの意味を持つエラーではありません。実装を読むと、409 を返す構築関数が3つあります。 1つ目は、同じ名前のものが既に存在する場合です。区分は AlreadyExists、文言は対象の名前に「already exists」を付けた形になります。 2つ目は、更新しようとした対象が、読み取ってから書き込むまでの間に他者に変更されていた場合です。区分は Conflict、文言は「Operation cannot be fulfilled on …」で始まり、中に「the object has been modified; please apply your changes to the latest version and try again」が入ります。 3つ目は、Server-Side Apply でフィールドの所有権が衝突した場合です。区分は同じ Conflict ですが、details.causes にフィールドごとの衝突と、その所有者の名前が入ります。文言は「Apply failed with N conflict(s)」の形です。 この3つは、対処が正反対です。1つ目は既存を使うか名前を変える。2つ目は読み直してからやり直す。3つ目は所有権を奪うか、手放すか、共有するかを選ぶ。同じ要求をそのまま送り直して直るものは、1つもありません。 したがって、409 を見たら最初にやるのは reason の確認、次に details の確認です。kubectl は区分を括弧付きで表示するので、Error from server (AlreadyExists) か Error from server (Conflict) かがそのまま手がかりになります。 エラーの概要 既に存在する場合の応答です。 { "kind": "Status", "status": "Failure", "message": "configmaps \"app-config\" already exists", "reason": "AlreadyExists", "details": { "kind": "configmaps", "name": "app-config" }, "code": 409 } 楽観ロックの競合は、区分も文言も変わります。 ...

冒頭まとめ GCP の 409 Conflict は、2つの異なる区分に対応します。エラー区分の定義ファイルを見ると、1つは作ろうとしたものが既に存在する場合、もう1つは同時実行の衝突で処理が中断された場合です。 この2つは、対処が正反対です。 前者は、状態が既に望みどおりになっている可能性があります。作成の操作を繰り返す自動化では、2回目以降は必ずこのエラーになります。異常として止めるのではなく、既にあるものを使う分岐を持つのが正しい作りです。 後者は、他の処理と衝突しました。定義には、この区分をどう扱うべきかが明示されています。実装する側への指針として、失敗した呼び出しだけを再試行してよいのが 503 の区分、上位の処理からやり直すべきなのがこの区分、系の状態が明示的に直されるまで再試行すべきでないのが 400 の区分、と3つが並べて説明されています。例として挙げられているのは、値を確認してから書き換える処理が失敗した場合で、読み取りから書き込みまでの一連の流れをやり直すべきだ、とされています。 つまり、同じ要求をそのまま送り直すのは、この区分に対しては誤った対処です。読み取りからやり直す必要があります。 したがって、409 を見たときに最初に読むべきは status の値です。ここで、待つのか、既存を使うのか、処理全体をやり直すのかが決まります。 エラーの概要 応答の形は他のエラーと共通です。既に存在する場合は次のようになります。 { "error": { "code": 409, "message": "The resource 'projects/my-project/zones/asia-northeast1-a/instances/my-vm' already exists", "status": "ALREADY_EXISTS" } } message に、既に存在する対象の完全な名前が入ります。自分が作ろうとした名前と同じであることを確認できます。 同時実行の衝突の場合は、区分名が変わります。 { "error": { "code": 409, "message": "Aborted due to cross-transaction contention.", "status": "ABORTED" } } こちらは対象の名前ではなく、衝突の理由が書かれます。同時に走っている処理があった、という趣旨の文言です。 コマンド行の道具からは、簡潔な形で表示されます。作成の操作を繰り返した場合、既に存在する旨がそのまま出ます。 まず最初に：status で3方向に振り分ける 第一に、status の値を読みます。ALREADY_EXISTS なら既に存在します。ABORTED なら同時実行の衝突です。 第二に、ALREADY_EXISTS であれば、既存のものが自分の望む状態かを確認します。同じ設定であれば、そのまま使えます。違えば、更新の操作に切り替えます。 第三に、ABORTED であれば、読み取りからやり直します。同じ要求の送り直しではありません。 第四に、FAILED_PRECONDITION が返っている場合は 409 ではなく 400 です。状態が整うまで待つ必要があります（GCP の 400 の記事）。混同しやすい3つですが、区分名で確実に分かれます。 ...

エラーの概要 HTTP 409 Conflict エラーは、GitLab 上でリソースの状態が競合している場合に発生します。既に存在するブランチやタグ名での作成、MergeRequest のソースとターゲットブランチの重複、あるいは同名のグループ・プロジェクトの存在などが典型的な原因です。このエラーが発生すると、意図した操作がブロックされ、リソースの作成や更新が完了しません。 実際のエラーメッセージ例 GitLab API の 409 エラーは、以下のようなレスポンスで返されます。 { "message": "409 Conflict" } REST API でより詳細な情報が返される場合もあります。 { "message": { "base": ["Branch already exists"] } } また、GitLab UI でブランチ作成時に失敗する場合は、以下のような通知メッセージが表示されます。 Error: A branch with name 'main' already exists よくある原因と解決手順 原因 1：既に存在するブランチ名またはタグ名で作成しようとしている ブランチやタグの作成時に、既に同名のリソースが存在する場合、409 エラーが発生します。これは Git の基本的な制約で、同じ名前空間内で重複するブランチやタグを持つことはできません。API 経由でのブランチ作成や、CI/CD パイプライン内での自動ブランチ生成時に特に注意が必要です。 Before（エラーが起きるコード）： # 既に 'develop' ブランチが存在する場合、同じ名前で再度作成しようとする curl --request POST https://gitlab.example.com/api/v4/projects/<project-id>/repository/branches \ --header "PRIVATE-TOKEN: <your-token>" \ --data "branch=develop&ref=main" After（修正後）： # 事前にブランチの存在を確認してから作成する RESPONSE=$(curl --request GET https://gitlab.example.com/api/v4/projects/<project-id>/repository/branches/develop \ --header "PRIVATE-TOKEN: <your-token>" \ --write-out "\n%{http_code}") HTTP_CODE=$(echo "$RESPONSE" | tail -1) # ブランチが存在しない場合（404）のみ作成 if [ "$HTTP_CODE" = "404" ]; then curl --request POST https://gitlab.example.com/api/v4/projects/<project-id>/repository/branches \ --header "PRIVATE-TOKEN: <your-token>" \ --data "branch=develop&ref=main" else echo "Branch already exists" fi 原因 2：MergeRequest のソースブランチとターゲットブランチが同じになっている MergeRequest を作成する際、ソースブランチとターゲットブランチが同じ場合に 409 エラーが発生します。これは論理的に無意味な操作（自分自身へのマージ）であるため、GitLab はこれを防止しています。複雑なパイプライン設定や自動化スクリプト内で、ブランチ変数の設定ミスにより起こることがあります。 ...

エラーの概要 Terraform の 409 エラーは、Terraform が作成・更新しようとするリソースが既にクラウド環境に存在し、状態ファイル（tfstate）に記録された期待値と実際のリソース状態に競合が生じていることを示します。このエラーは特にマルチユーザー環境や手動でリソースを作成した後に Terraform で管理を開始する場合に発生しやすくなります。 実際のエラーメッセージ例 Error: Error creating XXX: XXX (xxx): InvalidParameterException: Resource already exists on main.tf line 42, in resource "aws_instance" "web": 42: resource "aws_instance" "web" { Error: ConflictException { "error": "conflict", "message": "The resource with name 'my-bucket' already exists", "status_code": 409 } よくある原因と解決手順 原因 1：手動で作成したリソースを Terraform で管理しようとしている クラウド管理コンソールやコマンドラインで直接作成したリソースに対して、Terraform コードで同じリソースを定義すると、Terraform はそのリソースが「新規作成される対象」だと判断します。しかし実際にはリソースが存在するため、作成時に 409 エラーで競合が検出されます。 この場合、terraform import コマンドを使い、既存のリソースを Terraform の管理下に移す必要があります。 Before（エラーが起きるコード）： resource "aws_s3_bucket" "data_bucket" { bucket = "my-existing-bucket" } AWS マネジメントコンソールで my-existing-bucket が既に存在している場合、terraform apply 実行時に 409 エラーが発生します。 ...

エラーの概要 Azure 409 Conflict エラーは、リソースの現在の状態と API リクエストが競合している場合に発生します。通常、同じ名前のリソースが既に存在する、リソースがプロビジョニング途中である、または削除処理中の状態で新しい操作を実行しようとしたときに返されます。このエラーは Azure Portal、Azure CLI、Azure PowerShell、REST API など複数のインターフェースで発生する可能性があります。 実際のエラーメッセージ例 Azure REST API レスポンス： { "error": { "code": "Conflict", "message": "The resource 'myStorageAccount' already exists in the resource group 'myResourceGroup'.", "status": "409" } } Azure CLI の出力： (Conflict) The storage account myStorageAccount already exists. Code: Conflict Message: The storage account myStorageAccount already exists. よくある原因と解決手順 原因1：同じ名前のリソースが既に存在する 同じ名前のリソース（ストレージアカウント、App Service、Cosmos DB など）が既に同じリソースグループ内に存在すると、新規作成時に 409 Conflict が発生します。Azure の多くのリソースはグローバルに一意な名前を要求するため、他のリソースグループや他のサブスクリプションの同名リソースも競合の原因となります。 Before（エラーが起きるコード）： az storage account create \ --name myStorageAccount \ --resource-group myResourceGroup \ --location eastus After（修正後）： ...

エラーの概要 Docker Compose の 409 エラーは、リクエストされたコンテナーやネットワーク、ボリュームの状態が現在の環境状態と競合していることを示します。このエラーは通常、既に存在するリソースの作成を試みたり、使用中のポート・ネットワークを重複させたりした場合に発生します。既存の状態を認識しないまま操作を進めようとすると、Docker Compose がこの競合を検出して実行を中止します。 実際のエラーメッセージ例 パターン1：コンテナー名の競合 Error response from daemon: Conflict. The container name "<container-name>" is already in use by container "<existing-container-id>". You have to remove (or rename) that container to be able to reuse that name. パターン2：ポート番号の競合 ERROR: for <service-name> Cannot start service <service-name>: driver failed programming external connectivity on endpoint <endpoint-name>: Bind for 0.0.0.0:<port> failed: port is already allocated パターン3：ネットワークまたはボリュームの競合 Error response from daemon: network with name <network-name> already exists よくある原因と解決手順 原因1：同じ名前のコンテナーがすでに起動または停止状態で残っている Docker Compose は docker-compose.yml で定義したサービス名とプロジェクト名の組み合わせでコンテナー名を生成します。以前に作成したコンテナーが停止状態で残っていたり、同じ構成を再度実行しようとしたりすると、同じ名前のコンテナーが存在することになり、409 エラーが発生します。 修正方法： # 既存のコンテナーと関連リソースを完全に削除 docker compose down -v # その後、新たに起動 docker compose up -d -v フラグでボリュームも削除されるため、データの永続化が必要な場合は事前にバックアップを取得してください。 原因2：同じポートを複数のサービスが使おうとしている docker-compose.yml で複数のサービスが同じホストポートをバインドしようとしている場合、またはホストシステムの別のプロセスがすでにそのポートを使用している場合に 409 エラーが発生します。 修正方法： version: '3.8' services: web1: image: nginx:latest ports: - "8080:80" web2: image: nginx:latest ports: - "8081:80" 各サービスに異なるホストポートを割り当てることで競合を解決します。既にポートが使用されている場合は、以下のコマンドでホストマシン上の使用中ポートを確認できます。 ...

エラーの概要 AWSの409（Conflict）エラーは、リクエストの内容がAWSリソースの現在の状態と競合していることを示します。このエラーはS3、EC2、DynamoDB、CloudFormation、IAMなど複数のAWSサービスで発生し、リソースが完了していない状態遷移中であったり、既に同じ名前のリソースが存在していたりするときに返されます。一時的な問題か永続的な設定ミスかを判別することが解決の第一歩となります。 実際のエラーメッセージ例 S3バケット作成時: { "Error": { "Code": "BucketAlreadyExists", "Message": "The requested bucket name is not available. The bucket namespace is shared by all AWS accounts." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } EC2インスタンス操作時: { "Error": { "Code": "InvalidInstanceID.Transitional", "Message": "The instance ID 'i-1234567890abcdef0' is in a transitional state and cannot be modified at this time." }, "ResponseMetadata": { "HTTPStatusCode": 409 } } DynamoDBテーブル操作時: { "Error": { "Code": "ResourceInUseException", "Message": "Cannot update a table while an update is in progress" }, "ResponseMetadata": { "HTTPStatusCode": 409 } } よくある原因と解決手順 原因1：S3バケット名がグローバルに重複している S3のバケット名はAWS全体で一意である必要があります。既に別のAWSアカウントが使用しているバケット名を指定すると409エラーが発生します。 ...

エラーの概要 Dockerの409エラーは、HTTP標準仕様で「Conflict」を示すステータスコードです。Docker Daemonがコンテナやイメージの操作を受け付けられない状態を表します。通常、リソースの重複、ポートの競合、不正なコンテナの状態遷移などが原因となります。このエラーが発生した場合、現在のシステム状態と実行しようとしている操作に矛盾があることを意味しており、Dockerコマンド実行時やAPI呼び出し時に頻繁に遭遇します。 実際のエラーメッセージ例 { "message": "Error response from daemon: Conflict. The container name \"/web-app\" is already in use by container \"abc123def456\". You have to remove (or rename) that container to be able to reuse that name." } $ docker run --name myapp nginx docker: Error response from daemon: Conflict. The container name "/myapp" is already in use by container "e7f8c9a2b1d4". You have to remove (or rename) that container to be able to reuse that name. よくある原因と解決手順 原因1：コンテナ名の重複 同じ名前のコンテナが既に存在する場合、新たに同じ名前でコンテナを作成しようとすると409エラーが発生します。停止中のコンテナであっても名前は保持されるため、docker run --name で既存の名前を指定するとエラーになります。 ...

冒頭まとめ GitHub API の 409 Conflict は、リクエストの綴りや権限の問題ではなく、「リクエストの内容が対象の現在の状態と矛盾している」ことを示すコードです。GitHub 公式の API 定義（OpenAPI）で409が定義されているエンドポイントを調べると、実際の409は3系統に整理できます。第一に、本物のマージ競合です（ブランチのマージ API や上流ブランチとの同期 API が、競合時に409を返すと定義されています）。第二に、競合ガードです。対象が「あなたが見た時点」から動いたことを検出して操作を止める仕組みで、pull request のマージ API に sha を渡した場合の head 不一致や、ファイル更新（contents）API の sha 不一致がこれにあたります。第三に、リポジトリの状態が操作の前提を満たさないケースで、代表は空のリポジトリに対する Git 系・コミット系の API です（公式ガイドに、リポジトリが空または利用不能のとき REST API は 409 Conflict を返すと明記されています）。 同じくらい重要なのが、409だと思い込みやすいのに409ではないエラーです。「Reference already exists」（ブランチやタグが既に存在する）、「No commits between …」（差分のないプルリクエスト作成）、既存タグへのリリース作成は、いずれも 422 Validation Failed です。また、競合状態のプルリクエストをマージしようとした場合は 405 が定義されています。これらを409として調査すると出口のない回り道になるため、まずコードと系統の確認から始めます。 エラーの概要 409は「待てば直る」とも「直らない」とも一概に言えないコードで、系統によって正反対の対処になります。競合ガードの409は、最新の状態を取得し直して再実行するのが正しい対処です。マージ競合の409は、再試行しても同じ結果で、競合の解決そのものが必要です。空リポジトリの409は、初期化するまで何度でも返ります。 実際の応答例として、空のリポジトリのコミット一覧を取得した場合は次の形になります（公開されている実測記録と一致します）。 $ curl -i https://api.github.com/repos/<owner>/<empty-repo>/commits HTTP/2 409 ... { "message": "Git Repository is empty.", "documentation_url": "https://docs.github.com/rest/commits/commits#list-commits" } message の文言が、系統を見分ける最初の手がかりです。Git Repository is empty なら原因3、マージ操作への応答なら原因1か2、ファイル更新への応答なら原因2です。 まず最初に：どの操作への409かで3つに分岐する ブランチのマージ（POST …/merges）や上流との同期（POST …/merge-upstream）への409なら、マージ競合です（原因1）。pull request のマージ（PUT …/pulls/{n}/merge）への409は、リクエストに sha を渡している場合に head の移動を検出したガードです（原因2）。ファイルの作成・更新・削除（PUT / DELETE …/contents/{path}）への409も、並行更新による sha の食い違いというガードです（原因2）。コミット一覧や Git データベース系（git/refs、git/commits、git/trees など）の取得・作成への409で、message が Git Repository is empty なら、リポジトリが空です（原因3）。 ...