发布日期: 2026-04-15
版本号: v1.16.13

Dapr 1.16.13 版本更新主要包含以下修复内容：升级 Go 版本至 1.25.9 以修复已知安全漏洞；解决了多节点集群中调度器 Pod 重启后，计划任务可能长时间停止触发的问题，原因在于连接管理机制缺陷，现已改为独立重试以确保稳定性；修复了 Pulsar pub/sub 组件忽略元数据中 processMode 配置的问题，并限制了异步模式下的并发处理数量，防止资源无限消耗。

更新内容 （中文）

Dapr 1.16.13

此更新包含 Go 版本升级与错误修复：

Go 版本更新至 1.25.9

问题描述

Dapr 1.16.12 版本使用 Go 1.25.8 构建。 Go 1.25.9 包含对 crypto/x509、crypto/tls、archive/tar 和 html/template 包的安全修复。

影响范围

运行使用 Go 1.25.8 构建的 Dapr 的用户可能暴露在已在 Go 1.25.9 中修补的已知漏洞下。

解决方案

将 Go 版本从 1.25.8 更新至 1.25.9。

调度器 Pod 重启后定时任务停止触发

问题描述

当多节点集群中的调度器 Pod 重启时，所有定时任务可能在很长一段时间内或无限期停止触发。
Sidecar 的元数据端点持续报告已连接的调度器地址，但未向应用程序传递任何任务触发器。

影响范围

任何运行多副本调度器服务的部署都会受到影响。
在导致调度器 Pod 重启的常规操作期间，应用程序会停止接收定时任务触发器，直到不相关的集群事件重新建立连接。

根本原因

Sidecar 与每个调度器 Pod 维持流式连接以接收任务触发器。
这些连接由一个共享的运行器管理。当任意单个连接遇到错误时（例如被替换的调度器 Pod 在启动过程中短暂接受然后关闭连接），该运行器会取消所有连接，包括连接到其他调度器 Pod 的健康连接。
由于集群成员资格未发生变化，主机监听机制没有理由发出新事件，因此未尝试重连。

解决方案

每个连接到调度器的流式连接器现在在失败时独立重试，并带有半秒退避时间。
一个调度器连接上的临时故障不再影响连接到其他调度器 Pod 的健康连接。

Pulsar 发布/订阅组件忽略元数据中的 processMode 参数且缺乏异步背压机制

问题描述

Pulsar 发布/订阅组件在组件元数据（YAML）中设置 processMode 参数时被忽略。该参数仅从订阅请求元数据中读取，因此在组件 YAML 中配置了 processMode: async 或 processMode: sync 的用户会静默地以默认模式运行。此外，异步模式下每条消息会生成一个无限数量的 goroutine，没有并发限制。

影响范围

在 Pulsar 组件 YAML 中配置了 processMode 的应用程序未按预期处理模式运行。那些设置 processMode: sync 以为会进行同步有序处理的用户，实际上在以异步模式运行。

在异步模式下，每条传入消息都会生成一个新的 goroutine，且没有上限。在高消息速率下，这会导致无限未确认消息（在生产环境中观察到约 30k）、内存使用过多以及潜在的 OOM 崩溃。maxConcurrentHandlers 元数据字段控制通道缓冲区大小，但并未限制实际的并发 goroutine 数量。

根本原因

processMode 字段在 pulsarMetadata 结构体中缺失，因此从未从组件元数据中解析。它仅从每个订阅的请求元数据中读取，而大多数用户并未设置该值。

在异步模式下，跨 goroutine 的共享 err 变量导致了数据竞争，而 maxConcurrentHandlers 设置为 0 会导致死锁，而不是回退到默认值。

解决方案

processMode 参数现在能正确地从组件元数据中读取，每个订阅的元数据可以覆盖该设置。无效值在初始化时即被拒绝。

异步模式现在强制执行并发限制，当所有处理槽已满时应用背压，防止无限制的 goroutine 增长。将 maxConcurrentHandlers 设置为 0 会回退到默认值（100），而不是死锁。

此外，已修复异步模式中的数据竞争问题，并且优雅关闭现在会在返回前等待正在进行的处理程序完成。

更新内容 （原始）

Dapr 1.16.13

This update includes a Go version bump, and bug fixes:

Go version updated to 1.25.9

Problem

Dapr 1.16.12 was built with Go 1.25.8. Go 1.25.9 includes security fixes to the crypto/x509, crypto/tls, archive/tar, and html/template packages.

Impact

Users running Dapr built with Go 1.25.8 may be exposed to known vulnerabilities that have been patched in Go 1.25.9.

Solution

Updated the Go version from 1.25.8 to 1.25.9.

Scheduled jobs stop firing after a scheduler pod restart

Problem

When a scheduler pod in a multi-node cluster restarted, all scheduled jobs could stop firing for an extended or indefinite period. The sidecar’s metadata endpoint continued to report connected scheduler addresses, but no job triggers were delivered to the application.

Impact

Any deployment running the scheduler service with multiple replicas was affected. During routine operations that cause a scheduler pod to restart, applications stopped receiving scheduled job triggers until an unrelated cluster event happened to re-establish the connections.

Root Cause

The sidecar maintains a streaming connection to each scheduler pod for receiving job triggers. These connections were managed by a shared runner. When any single connection encountered an error (such as the replaced scheduler pod briefly accepting then closing the connection during startup), the runner cancelled all connections, including healthy ones to the other scheduler pods. No reconnection was attempted because the host-watching mechanism had no reason to emit a new event when cluster membership had not changed.

Solution

Each per-scheduler streaming connector now retries independently on failure with a half-second backoff. A transient failure on one scheduler connection no longer affects healthy connections to other scheduler pods.

Pulsar pub/sub ignores processMode from component metadata and lacks async backpressure

Problem

The Pulsar pub/sub component ignored the processMode parameter when set in component metadata (YAML). The parameter was only read from subscription request metadata, so users who configured processMode: async or processMode: sync in the component YAML were silently running in the default mode. Additionally, async mode spawned an unbounded number of goroutines per message with no concurrency limit.

Impact

Applications that configured processMode in the Pulsar component YAML were not running in the expected processing mode. Users who set processMode: sync thinking they had synchronous, ordered processing were actually running in async mode.

In async mode, every incoming message spawned a new goroutine with no upper bound. Under high message rates, this caused unbounded unacked messages (~30k observed in production), excessive memory usage, and potential OOM crashes. The maxConcurrentHandlers metadata field controlled a channel buffer size but did not limit actual concurrent goroutines.

Root Cause

The processMode field was missing from the pulsarMetadata struct, so it was never parsed from component metadata. It was only read from the per-subscription request metadata, which most users do not set.

In async mode, a shared err variable across goroutines caused a data race, and maxConcurrentHandlers set to 0 caused a deadlock instead of falling back to a default value.

Solution

The processMode parameter is now correctly read from component metadata, with per-subscription metadata able to override it. Invalid values are rejected at initialization time.

Async mode now enforces a concurrency limit that applies backpressure when all handler slots are full, preventing unbounded goroutine growth. Setting maxConcurrentHandlers to 0 falls back to the default (100) instead of deadlocking.

Additionally, a data race in async mode was fixed, and graceful shutdown now waits for in-flight handlers before returning.

下载链接