发布日期: 2026-08-06
版本号: v1.16.18

Dapr 1.16.18 版本修复了一个导致输入绑定无法激活的 bug。该问题发生于应用在启动后对订阅发现探测的响应较慢时：在启用绑定之前，daprd 会向应用发送探测请求（HTTP OPTIONS 或 gRPC ListInputBindings），该请求有固定的 3 秒超时。若应用在此时限内未完成启动响应，绑定将被标记为未订阅且永不激活，尽管组件初始化正常且显示为健康状态，但事件不会被投递，对于 HTTP 通道还可能中断其他绑定。此问题主要影响启动缓慢的应用（如 JVM 预热、复杂依赖注入或资源受限节点），且未在绑定元数据中明确设置 direction: input 的场景。根本原因是超时时间被硬编码为 3 秒且无法配置或取消。新版本引入了 --app-binding-options-timeout 标志以允许配置该超时（默认仍为 3 秒），并将探测上下文绑定至运行时，确保在关闭时能及时取消探测。显式设置 direction: input 仍可跳过探测。

更新内容 （中文）

Dapr 1.16.18

此更新包含以下错误修复：

应用响应订阅发现探测缓慢时输入绑定未激活

问题

在从输入绑定读取数据之前，daprd 会向应用发送请求以确认其是否订阅该绑定：该请求为向绑定路由发送的 HTTP OPTIONS 请求或 gRPC ListInputBindings 调用。 此请求被赋予硬编码的 3 秒时限，且无法更改。 若应用在 3 秒内未完成预热，则无法及时响应，导致 daprd 将该绑定视为未订阅状态并永远不予激活。

影响

若您的应用在启动后响应首个请求缓慢（如 JVM/JIT 预热、大型依赖注入图或资源受限节点），且声明的输入绑定未显式设置 direction: input 元数据条目，则会受到影响。 绑定组件本身初始化正常，且在 Sidecar 的元数据端点中显示，因此组件看似健康，但事件始终不会被传递。 对于 HTTP 通道，失败的探测会中止后续所有绑定的检查，导致该 Sidecar 上所有输入绑定处于非活动状态；唯一的痕迹是 Sidecar 日志中的 failed to read from bindings 警告。 对于 gRPC 通道，探测失败静默发生。

根本原因

订阅发现的超时时间在绑定处理器中硬编码为 3 秒，且基于后台上下文创建。 该机制无法为启动缓慢的应用调整超时，也无法在探测仍在进行时随运行时关闭而取消探测。

解决方案

超时时间现在可通过新的 daprd --app-binding-options-timeout 标志配置，该标志同时适用于 HTTP OPTIONS 探测和 gRPC ListInputBindings 探测。 默认值仍为 3 秒，因此现有部署不受影响，非正数值将回退至该默认值。 探测现在派生自运行时上下文，因此在关闭时会立即取消，而非运行至完整时限。

在绑定组件上设置 direction: input 仍可完全跳过探测。

更新内容 （原始）

Dapr 1.16.18

This update contains the following bug fix:

Input bindings not activated when the app is slow to answer the subscription discovery probe

Problem

Before it starts reading from an input binding, daprd asks the application whether it subscribes to that binding: an HTTP OPTIONS request to the binding’s route, or a gRPC ListInputBindings call. This request was given a hardcoded 3 second budget with no way to change it. An application that had not finished warming up within those 3 seconds never answered in time, so daprd treated the binding as unsubscribed and never activated it.

Impact

You were affected if your application is slow to serve its first request after startup — JVM or JIT warmup, large dependency-injection graphs, or resource-constrained nodes — and you declared an input binding without an explicit direction: input metadata entry.

The binding component itself initialized correctly and appeared in the sidecar’s metadata endpoint, so the component looked healthy while no events were ever delivered. On the HTTP channel a failed probe also aborted the remaining bindings, leaving every input binding on that sidecar inactive; the only trace was a failed to read from bindings warning in the sidecar log. On the gRPC channel the probe failure was silent.

Root Cause

The subscription discovery deadline was hardcoded to 3 seconds in the binding processor and built from a background context. It could neither be tuned for applications with slow startup nor cancelled when the runtime shut down while a probe was still in flight.

Solution

The timeout is now configurable through the new daprd --app-binding-options-timeout flag, which applies to both the HTTP OPTIONS probe and the gRPC ListInputBindings probe. The default remains 3 seconds, so existing deployments are unchanged, and non-positive values fall back to that default. The probe is now derived from the runtime’s context, so it is cancelled promptly on shutdown instead of running to its full deadline.

Setting direction: input on the binding component continues to skip the probe entirely.

下载链接