From 85a59ea8e67ec212cc79d2c5376e7461f71cc4b9 Mon Sep 17 00:00:00 2001 From: Roberto Rojas Date: Thu, 29 Jun 2023 14:43:25 -0400 Subject: [PATCH] Update daprdocs/content/en/reference/api/bindings_api.md Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: Roberto Rojas --- daprdocs/content/en/reference/api/bindings_api.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daprdocs/content/en/reference/api/bindings_api.md b/daprdocs/content/en/reference/api/bindings_api.md index 0754479ac..d7170ff7b 100644 --- a/daprdocs/content/en/reference/api/bindings_api.md +++ b/daprdocs/content/en/reference/api/bindings_api.md @@ -51,7 +51,7 @@ Here a few scenarios when the `"direction"` metadata field could help: - When an application (detached from the sidecar) runs as a serverless workload and is scaled to zero, the `"wait for the app to become ready"` check done by the Dapr sidecar becomes pointless. -- If the detached dapr sidecar is what is scaled to 0 and the first thing the application does (before even start an http server) is reaching the sidecar the "wait for the app to become ready" gets the app and the sidecar into a dead lock of both ends waiting for each other. +- If the detached Dapr sidecar is scaled to zero and the application reaches the sidecar (before even starting an HTTP server), the `"wait for the app to become ready"` deadlocks the app and the sidecar into waiting for each other. ### Example