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 Eventing 实现不支持Retry-After标头，这是一种尝试为标准化该支持提供一条路径。首先，该功能是选择加入的，但最终状态将是选择退出，如下所示

功能阶段	功能标志	retryAfterMax 字段缺失	retryAfterMax 字段存在
Alpha / Beta	已禁用	被 Webhook 验证接受，并且不强制执行 Retry-After 标头	被 WebHook 验证拒绝
Alpha / Beta	已启用	被 Webhook 验证接受，并且不强制执行 Retry-After 标头	被 Webhook 验证接受，并且如果最大覆盖值 > 0，则强制执行 Retry-After 标头
稳定 / GA	n/a	强制执行 Retry-After 标头，无需最大覆盖	如果最大覆盖值 > 0，则强制执行 Retry-After 标头

以下示例显示了一个 Subscription，它重试发送事件三次，并尊重Retry-After标头，同时将最大退避时间限制为 120 秒

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 验证强制执行对 retryAfterMax 字段的所有 DeliverySpec 使用，但它不能保证所有实现（如 Channel 或 Source）实际上都实现了对该字段的支持。共享的 HTTPMessageSender.SendWithRetries() 逻辑已得到增强以支持此功能，并且使用它执行重试的所有实现将自动受益。未基于此共享库的扩展实现（例如 RabbitMQ 或 Google Pub/Sub）将需要额外的开发工作才能尊重 retryAfterMax 字段。