DeliverySpec.RetryAfterMax 欄位

旗標名稱: delivery-retryafter

階段: Alpha，預設為停用

追蹤問題: #5811

角色: 開發人員

當使用 delivery 規格來設定事件傳遞參數時，您可以使用 retryAfterMax 欄位來指定在計算重試 429 和 503 回應的回退時間時，如何處理 HTTP Retry-After 標頭。您可以為 Channel、Subscription、Broker、Trigger 以及任何其他接受 delivery 欄位的資源規格指定 delivery 規格。

retryAfterMax 欄位僅在您設定 delivery 規格以執行重試時生效，並且僅適用於對 429 和 503 回應代碼的重試嘗試。此欄位提供覆寫，以防止大型 Retry-After 持續時間影響輸送量，並且必須使用 ISO 8601 格式指定。正常回退持續時間和 Retry-After 標頭值的最大值將用於後續的重試嘗試。指定 PT0S 的「零」值實際上會停用 Retry-After 支援。

在此功能之前，Knative 事件處理實作並未支援 Retry-After 標頭，而這是一個嘗試提供標準化支援途徑的方法。首先，此功能是 選擇加入，但最終狀態將會是 選擇退出，如下所示

功能階段	功能旗標	retryAfterMax 欄位不存在	retryAfterMax 欄位存在
Alpha / Beta	已停用	Webhook 驗證接受 & Retry-After 標頭不強制執行	Webhook 驗證拒絕
Alpha / Beta	已啟用	Webhook 驗證接受 & Retry-After 標頭不強制執行	Webhook 驗證接受 & 如果最大覆寫 > 0，則強制執行 Retry-After 標頭
穩定 / GA	不適用	強制執行 Retry-After 標頭，無需最大覆寫	如果最大覆寫 > 0，則強制執行 Retry-After 標頭

以下範例顯示 Subscription 重試傳送事件三次，並在強制執行 120 秒的最大回退時間的同時，遵守 Retry-After 標頭

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: example-subscription
  namespace: example-namespace
spec:
  subscriber:
    ref:
      apiVersion: serving.knative.dev/v1
      kind: Service
      name: example-sink
  delivery:
    backoffDelay: PT2S
    backoffPolicy: linear
    retry: 3
    retryAfterMax: PT120S

注意

雖然功能旗標透過 Webhook 驗證強制執行 DeliverySpec 的所有 retryAfterMax 欄位使用，但不保證所有實作（例如 Channel 或 Source）實際上都實作了對此欄位的支援。已增強共用的 HTTPMessageSender.SendWithRetries() 邏輯以支援此功能，並且所有使用它來執行重試的實作都會自動受益。非基於此共用程式庫的擴充實作（例如 RabbitMQ 或 Google Pub/Sub）將需要額外的開發工作才能遵循 retryAfterMax 欄位。