Back to Dapr

Dapr 1.17.12

docs/release_notes/v1.17.12.md

1.18.33.0 KB
Original Source

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.