docs/release_notes/v1.16.18.md
This update contains the following bug fix:
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.
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.
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.
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.