[1.18] Updates resiliency of streaming HTTP Service Invocation

daprdocs/content/en/developing-applications/building-blocks/service-invocation/service-invocation-overview.md

@@ -61,6 +61,10 @@ For more information read the [service-to-service security]({{% ref "security-co
 
 In the event of call failures and transient errors, service invocation provides a resiliency feature that performs automatic retries with backoff time periods. To find out more, see the [Resiliency article here]({{% ref resiliency-overview %}}).
 
+{{% alert title="Note" color="primary" %}}
+For HTTP service invocation, retry policies (both built-in and user-configured) are automatically bypassed for streaming requests (those using chunked transfer encoding or without a known `Content-Length`). Since the request body is consumed as it is read, it cannot be replayed on retry. Non-streaming requests with a known `Content-Length` continue to support retries as before. See [Streaming for HTTP service invocation](#streaming-for-http-service-invocation) for more details.
+{{% /alert %}}
+
 ### Tracing and metrics with observability
 
 By default, all calls between applications are traced and metrics are gathered to provide insights and diagnostics for applications. This is especially important in production scenarios, providing call graphs and metrics on the calls between your services. For more information read about [observability]({{% ref observability-concept %}}).
@@ -102,7 +106,7 @@ The Consul name resolution component is particularly suited to multi-machine dep
 
 You can handle data as a stream in HTTP service invocation. This can offer improvements in performance and memory utilization when using Dapr to invoke another service using HTTP with large request or response bodies.
 
-The diagram below demonstrates the six steps of data flow. 
+The diagram below demonstrates the six steps of data flow.
 
 <img src="/images/service-invocation-simple.webp" width=600 alt="Diagram showing the steps of service invocation described in the table below" />
 
@@ -113,6 +117,16 @@ The diagram below demonstrates the six steps of data flow.
 1. Response: "Dapr sidecar B" to "Dapr sidecar A"
 1. Response: "Dapr sidecar A" to "App A"
 
+#### Streaming requests and resiliency
+
+Dapr automatically detects streaming HTTP requests — those using chunked transfer encoding or without a known `Content-Length` header (for example, file uploads, piped bodies, or long-running data streams). For these requests:
+
+- **Request bodies are not buffered in memory.** The sidecar forwards the request body directly as it is read, avoiding excessive memory usage for large payloads.
+- **Response bodies are not buffered in memory.** Streaming responses (such as server-sent events, file downloads, or long-running data streams) are forwarded directly to the caller.
+- **Retry policies are bypassed.** Both built-in retry logic and any user-configured [resiliency retry policies]({{% ref resiliency-overview %}}) are automatically skipped, since the request body is consumed as it is read and cannot be replayed.
+- **Other resiliency features still apply.** Circuit breakers continue to track failures normally for streaming requests.
+- **Non-streaming requests are unaffected.** Requests with a known `Content-Length` continue to support retries and buffered error handling as before.
+
 ## Example Architecture
 
 Following the above call sequence, suppose you have the applications as described in the [Hello World tutorial](https://github.com/dapr/quickstarts/blob/master/tutorials/hello-world/README), where a python app invokes a node.js app. In such a scenario, the python app would be "Service A" , and a Node.js app would be "Service B".

daprdocs/content/en/operations/resiliency/policies/retries/retries-overview.md

@@ -20,6 +20,10 @@ Dapr provides [default resiliency policies]({{% ref default-policies.md %}}), wh
 Each [pub/sub component]({{% ref supported-pubsub %}}) has its own built-in retry behaviors. Explicity applying a Dapr resiliency policy doesn't override these implicit retry policies. Rather, the resiliency policy augments the built-in retry, which can cause repetitive clustering of messages.
 {{% /alert %}}
 
+{{% alert title="Note" color="primary" %}}
+For HTTP [service invocation]({{% ref service-invocation-overview %}}), retry policies are automatically bypassed for streaming requests (those using chunked transfer encoding or without a known `Content-Length`). Since the request body is consumed as it is read, it cannot be replayed on retry. Non-streaming requests with a known `Content-Length` continue to support retries as before. Learn more about [streaming HTTP service invocation and resiliency]({{% ref "service-invocation-overview#streaming-requests-and-resiliency" %}}).
+{{% /alert %}}
+
 ## Retry policy format
 
 **Example 1**

daprdocs/content/en/operations/resiliency/targets.md

@@ -19,6 +19,8 @@ With the `apps` target, you can apply `retry`, `timeout`, and `circuitBreaker` p
 
 > Dapr provides [built-in service invocation retries]({{% ref "service-invocation-overview.md#retries" %}}), so any applied `retry` policies are additional.
 
+> For HTTP service invocation, `retry` policies are automatically bypassed for streaming requests (those without a known `Content-Length`). Circuit breakers continue to apply. See [Streaming requests and resiliency]({{% ref "service-invocation-overview#streaming-requests-and-resiliency" %}}).
+
 <img src="/images/resiliency_svc_invocation.png" width=1000 alt="Diagram showing service invocation resiliency" />
 
 Example of policies to a target app with the `app-id` "appB":