发布日期: 2026-08-14
版本号: v1.17.13

Dapr 1.17.13版本更新修复了三个错误：一是解决了工作流在特定条件下永久卡死的问题，当最后的工作流工作者断开连接时，处于停滞状态的工作流现在会自动恢复而非要求重启daprd；二是修复了Azure组件认证链在SPIFFE凭证处中断而不向后续凭证回退的问题，确保认证流程能正常继续；三是解决了SPIFFE SVID源未正确传播到组件操作调用上下文的问题，使得组件能在每次操作中使用SPIFFE ID进行认证。

更新内容 （中文）

Dapr 1.17.13

本次更新包含以下错误修复：

工作流在最后一个工作流工作者断开连接后永久停滞

问题

进入 STALLED 状态（版本不可用、补丁不匹配或负载大小超限）的工作流，如果在停滞期间最后一个连接的工作流工作者断开连接，可能会永久卡住。 重新连接的工作流工作者（包括注册了该停滞所等待的确切工作流版本的工作流工作者）也无法恢复该工作流：状态查询持续报告 STALLED，唯一的恢复方法是重启 daprd。 发生时，sidecar 会记录以下日志：

error while disconnecting work item stream: failed to deactivate workflow '<id>': actor is stalled

影响

设计停滞机制的目的，正是为了确保工作流能在工作者离开后存活，并在有能力的工作者返回时恢复，这通常发生在滚动升级场景中（旧应用版本断开连接，新版本重新连接）。 如果您使用了工作流版本控制、补丁，或配置了 --max-body-size，并且在工作流停滞期间，某个应用的所有工作流工作者都断开连接（例如在应用重启、滚动升级、缩容至零，或启用了 WorkflowsClusteredDeployment 的负载均衡器后面），您可能会受到影响。

根本原因

停滞的工作流 Actor 会在进程内暂停其执行，持有未确认的执行提醒，直到其上下文被取消，并将其锁标记为已停滞。 当最后一个工作流工作者断开连接时，daprd 会取消注册工作流 Actor 类型并停用所有工作流 Actor，但停用操作始于获取 Actor 的锁，而当 Actor 处于停滞状态时，锁会拒绝获取。 工作流后续能否恢复取决于一个竞态条件：如果调度器的提醒流拆除在停用操作到达 Actor 之前取消了暂停的执行，则停用成功，并且未确认的提醒会在工作者重新连接时重新传递；如果停用操作赢得了竞态条件，则操作因 actor is stalled 而失败，导致 Actor 保持激活状态并持有未完成的提醒，因此重新连接的工作流工作者无内容可重新传递，工作流永远不会重新执行。

解决方案

现在，停用一个停滞的工作流 Actor 会唤醒暂停的执行，而不是失败：被持有的执行会立即返回，留下未确认的执行提醒，停用操作得以完成。 当工作流工作者重新连接时，提醒会被重新传递，工作流会重新执行，一旦连接的工作者满足停滞条件（例如注册了所需的工作流版本，或使用更大的 --max-body-size 重启了 daprd），即可恢复并完成。 从停滞中恢复不再依赖于时机，也不再需要重启 daprd。

Azure组件认证在SPIFFE凭证处中止，而非回退

问题

Azure（Microsoft Entra ID）组件通过按顺序尝试凭证链中的凭证进行认证，直到其中一个成功为止。 当设置了 azureClientId 和 azureTenantId 时，凭证链会包含 SPIFFE 工作负载身份凭证。如果没有可用的 SPIFFE JWT SVID 源，链条会在此步骤停止：

ChainedTokenCredential: failed to acquire a token.
Attempted credentials:
	ClientAssertionCredential: failed to get JWT SVID source from context

链条中后续的凭证（例如托管身份或 Azure CLI）从未被尝试，因此即使存在可用的有效凭证，组件也无法完成认证。

影响

如果您使用的是 Dapr 1.16.0 或更高版本（SPIFFE 凭证加入了默认凭证链），并且在以下任一配置中，您可能会受到影响：

  • 一个设置了 azureClientId 和 azureTenantId，但未设置客户端密码或证书的 Azure 组件，依赖于默认凭证链中的后续凭证（例如托管身份或 Azure CLI）。
  • 一个显式的 azureAuthMethods 列表，将 spiffeworkloadidentity 放在其他方法之前（例如 spiffeworkloadidentity,managedidentity），期望在 SPIFFE 未配置时回退到其他方法。

根本原因

ChainedTokenCredential 只有在凭证报告 credentialUnavailableError 时才会继续尝试下一个凭证；任何其他错误都被视为致命错误并终止链条。 当上下文未携带 JWT SVID 源时，SPIFFE 凭证会返回一个普通错误，因此缺失的前提条件被视为致命的认证失败，而不是尝试下一个凭证的信号。

解决方案

现在，SPIFFE 凭证在未找到 JWT SVID 源时，在进行任何令牌请求之前就会报告其自身不可用，这正是 ChainedTokenCredential 需要以继续尝试链条中下一个凭证的信号。 无论是默认凭证链还是显式排序的 azureAuthMethods 列表，现在都能如预期那样回退，而当配置了 SPIFFE 源时的行为保持不变。

SPIFFE SVID组件操作传播

问题

SPIFFE SVID 源未传播到组件操作调用中。因此，任何希望使用 SPIFFE ID 进行身份验证的组件都必须在其 init 方法中捕获该源并显式管理它。诸如 Azure SDK 之类的 SDK（当上下文中存在 SPIFFE SVID 源时能够透明地使用它）则无法做到这一点。

影响

Azure 组件如果不显式处理该源，就无法利用 SPIFFE ID 进行身份验证，这也阻碍了未来其他组件对基于 SPIFFE 的身份验证的支持。

根本原因

SPIFFE SVID 源仅附加到组件的 init 方法上下文中，而未附加到传入操作调用的上下文中。

解决方案

现在，SPIFFE SVID 源已附加到传入操作调用的上下文中，允许组件根据每次操作使用 SPIFFE ID 进行身份验证。

更新内容 （原始）

Dapr 1.17.13

This update contains the following bug fixes:

Stalled workflows permanently stuck after the last workflow worker disconnects

Problem

A workflow that entered the STALLED state (version not available, patch mismatch, or payload size exceeded) could become permanently stuck if the last connected workflow worker disconnected while the workflow was stalled. Reconnecting workers, including workers registering the exact workflow version the stall was waiting for, did not resume it: status queries kept reporting STALLED and the only recovery was restarting daprd. When it occurred, the sidecar logged:

error while disconnecting work item stream: failed to deactivate workflow '<id>': actor is stalled

Impact

Stalling exists precisely so that a workflow survives its workers going away and resumes once capable workers return, most commonly a rolling upgrade where the old application version disconnects and the new version reconnects. You were affected if you use workflow versioning, patching, or a configured --max-body-size, and all workflow workers of an application disconnected while a workflow was stalled; for example during application restarts, rolling upgrades, scale-to-zero, or behind a load balancer with WorkflowsClusteredDeployment enabled.

Root Cause

A stalled workflow actor parks its execution in-process, holding the execution reminder in flight until its context is cancelled, and marks its lock as stalled. When the last workflow worker disconnects, daprd unregisters the workflow actor types and deactivates all workflow actors, but deactivation begins by acquiring the actor’s lock, and the lock rejects acquisition while the actor is stalled. Whether the workflow could later recover came down to a race: if the scheduler’s reminder stream teardown cancelled the parked execution before deactivation reached the actor, deactivation succeeded and the unacknowledged reminder was redelivered when workers reconnected; if deactivation won the race, it failed with actor is stalled, leaving the actor activated and holding the reminder in flight, so reconnecting workers had nothing to redeliver and the workflow never re-executed.

Solution

Deactivating a stalled workflow actor now wakes the parked execution instead of failing: the held execution returns immediately, leaving the execution reminder unacknowledged, and deactivation completes. When workflow workers reconnect, the reminder is redelivered and the workflow re-executes, resuming and completing once the connected workers satisfy the stall condition (for example the required workflow version is registered, or daprd was restarted with a larger --max-body-size). Recovery from a stall no longer depends on timing, and a daprd restart is no longer required.

Azure component authentication halting at the SPIFFE credential instead of falling back

Problem

Azure (Microsoft Entra ID) components authenticate by trying a chain of credentials in order until one succeeds. When azureClientId and azureTenantId were set, the chain included the SPIFFE workload identity credential, and if no SPIFFE JWT SVID source was available the chain stopped at that step:

ChainedTokenCredential: failed to acquire a token.
Attempted credentials:
	ClientAssertionCredential: failed to get JWT SVID source from context

Credentials later in the chain, such as managed identity or the Azure CLI, were never attempted, so the component failed to authenticate even though a working credential was available.

Impact

You were affected on Dapr 1.16.0 or later (where the SPIFFE credential joined the default chain) in either of these configurations:

  • An Azure component with azureClientId and azureTenantId set but no client secret or certificate, relying on a later credential in the default chain (for example managed identity or the Azure CLI).
  • An explicit azureAuthMethods list placing spiffeworkloadidentity before another method (for example spiffeworkloadidentity,managedidentity), expecting fallback when SPIFFE is not configured.

Root Cause

ChainedTokenCredential only continues past a credential that reports a credentialUnavailableError; any other error is treated as fatal and ends the chain. The SPIFFE credential returned a plain error when the context carried no JWT SVID source, so a missing prerequisite was treated as a fatal authentication failure rather than a signal to try the next credential.

Solution

The SPIFFE credential now reports itself as unavailable when no JWT SVID source is present, before any token request is made, which is exactly what ChainedTokenCredential requires to continue to the next credential in the chain. Both the default chain and explicitly ordered azureAuthMethods lists now fall through as expected, and behavior when a SPIFFE source is configured is unchanged.

SPIFFE SVID component operation propagation

Problem

The SPIFFE SVID source was not propagated to component operation calls. As a result, any component that wanted to use the SPIFFE ID for authentication had to capture the source in its init method and manage it explicitly. SDKs such as the Azure SDK, which can transparently use the SPIFFE SVID source when it is present on the context, were unable to do so.

Impact

Azure components could not leverage the SPIFFE ID for authentication without explicitly handling the source, and this also blocked future support for SPIFFE-based authentication in other components.

Root Cause

The SPIFFE SVID source was attached only to the component’s init method context, not to the context passed into operation calls.

Solution

The SPIFFE SVID source is now attached to the context passed into operation calls, allowing components to use the SPIFFE ID for authentication on a per-operation basis.

下载链接