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

Dapr 1.17.12版本包含两项主要更新：一是将构建所用的Go版本从1.26.4升级至1.26.5，以修复Go标准库及工具链中的已知安全漏洞；二是解决了当应用程序对订阅发现探测响应缓慢时，输入绑定可能无法激活的问题，现通过新增--app-binding-options-timeout标志使该超时时间可配置，并优化了探测的上下文处理。

更新内容 （中文）

Dapr 1.17.12

本次更新包含以下变更：

将 Go 更新至 1.26.5 版本

问题描述

Dapr 此前使用 Go 1.26.4 构建，govulncheck 检测发现该版本受 Go 标准库和工具链中已知漏洞的影响。

影响范围

运行 Dapr 1.17.11 或更早版本的用户受到影响。风险暴露程度取决于所报告漏洞涵盖的标准库包；具体修复的问题请参阅 Go 1.26.5 发行说明。

根本原因

问题源自 Go 标准库和工具链，而非 Dapr 代码本身。

解决方案

构建 Dapr 所使用的 Go 版本已从 1.26.4 更新至 1.26.5，涵盖运行时、构建工具和容器镜像。

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

问题描述

在从输入绑定开始读取之前，daprd 会向应用询问是否订阅该绑定：向绑定路由发送 HTTP OPTIONS 请求，或调用 gRPC ListInputBindings 接口。 该请求原本硬编码为 3 秒超时且无法配置。 若应用在 3 秒内未能完成预热响应，daprd 会将该绑定视为未订阅状态且永不激活。

影响范围

如果您的应用启动后首次请求响应缓慢（例如 JVM 或 JIT 预热、大型依赖注入图或资源受限节点），且声明了输入绑定但未明确设置 direction: input 元数据条目，则会受到影响。

绑定组件本身初始化正常，且出现在边车的元数据端点中，因此组件显示健康状态却始终无法接收事件。 在 HTTP 通道上，探针失败还会中止剩余绑定的处理，导致该边车所有输入绑定均未激活；唯一的痕迹是边车日志中出现 failed to read from bindings 警告。 在 gRPC 通道上，探针失败则无任何提示。

根本原因

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

解决方案

超时现在可通过新增的 daprd --app-binding-options-timeout 参数配置，该参数同时适用于 HTTP OPTIONS 探针和 gRPC ListInputBindings 探针。 默认值仍为 3 秒，因此现有部署不受影响；非正数配置将回退至默认值。 探针现在基于运行时上下文创建，因此在关闭时会立即取消，而非持续到完整的超时时长。

在绑定组件上设置 direction: input 仍会完全跳过探针检查。

更新内容 （原始）

Dapr 1.17.12

This update contains the following changes:

Update Go to 1.26.5

Problem

Dapr was built with Go 1.26.4, which govulncheck reported as affected by known vulnerabilities in the Go standard library and toolchain.

Impact

Users running Dapr 1.17.11 or earlier are affected. The exposure depends on which standard library packages the reported vulnerabilities cover; see the Go 1.26.5 release notes for the specific issues fixed.

Root Cause

The issues originated in the Go standard library and toolchain rather than in Dapr code.

Solution

The Go version used to build Dapr has been updated from 1.26.4 to 1.26.5 across the runtime, build tooling, and container images.

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.

下载链接