Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Resource Provider Guidance Needed for Capacity Exhaustion and Capacity-Constrained Responses

オープン
  • 何か問題がありますか？
#595 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
領域
api, documentation

調査の方向性

The issue is about adding guidance to the ARM/RP contract. Start by reviewing the existing Microsoft REST API Guidelines, particularly sections on error handling and HTTP status codes. Look for existing documentation on error codes like 'Throttled' or 'InternalServerError' to understand the current structure. 'Done' means the proposed guidance is integrated into the guidelines, with clear examples for the new error codes and the x-ms-failure-cause mapping.

索引モデルが issue の本文から書いたものです。

説明

Description

The Azure ecosystem currently lacks clear, Azure-wide guidance for Resource Providers on how to surface capacity-related failures to customers.

Today, similar capacity constraints are exposed inconsistently across Azure using a mix of:

  • 400 BadRequest
  • 409 Conflict
  • 429 TooManyRequests
  • 500 InternalServerError
  • RP-specific error codes and semantics

This inconsistency makes it difficult for customers, SDKs, ARM tooling, and dependent Azure services to reliably distinguish between:

  • Invalid requests that require customer action
  • Resource conflicts
  • Request throttling
  • Temporary service-side capacity shortages
  • Unexpected RP failures

Capacity exhaustion is fundamentally different from both a malformed request and an internal implementation error. A valid request may become satisfiable later without modification, yet there is currently no documented ARM / RP guidance defining the expected HTTP status code, error contract, retry semantics, or failure classification.

Proposal

Add explicit guidance to the ARM / RP contract for temporary capacity shortages.

Recommended response:

503 Service Unavailable
Retry-After: <optional>
x-ms-error-code: InsufficientCapacity

{
  "error": {
    "code": "InsufficientCapacity",
    "message": "The service currently has insufficient capacity to fulfill this request."
  }
}

Additionally, define a small set of canonical capacity-related error codes, for example:

  • InsufficientCapacity
  • RegionalCapacityExceeded
  • ZonalCapacityExceeded
  • SkuCapacityUnavailable
  • PlacementCapacityUnavailable

and document expected retry behavior for each.

x-ms-failure-cause Guidance

Provide explicit guidance for x-ms-failure-cause so capacity shortages can be distinguished from throttling and implementation defects.

Scenario HTTP Error Code x-ms-failure-cause
Temporary capacity shortage 503 InsufficientCapacity service
RP throttling 429 Throttled service
ARM throttling 429 TooManyRequests gateway
Unexpected RP failure 500 InternalServerError service

This would allow Azure services and customers to handle capacity conditions consistently across Resource Providers while improving diagnostics, automation, and customer experience.

主要言語
言語のデータがありません
スター
23.3k
フォーク
2.7k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/api-guidelines のほかの issue

microsoft/api-guidelines の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。