Clarify renderer warmup docs

Author: justin808

docs/oss/configuration/configuration-pro.md

@@ -204,13 +204,13 @@ Guidance:
 - Account for your Rails concurrency: with many Puma threads/workers all streaming, a renderer with only one or two workers becomes the bottleneck. Scale `workersCount` (and renderer replicas) to your real concurrent streamed-render load.
 - Raise `ssr_timeout` for long-running streamed responses — it is the socket idle timeout for the streaming connection. It fires when the renderer sends no data for `ssr_timeout` seconds, not when the total response duration exceeds that value.
 
-### 3. Rails ↔ renderer keep-alive (already on for streaming)
+### 3. Rails ↔ renderer keep-alive (persistent on Falcon/async scheduler; per-request on standard Puma)
 
 Connection reuse is automatic when the renderer request runs under a long-lived `Fiber.scheduler`, such as Falcon or Puma configured with an async scheduler. In that setup, the async-http client is stored on the scheduler and reused across streaming requests, so HTTP/2 connections stay alive and renders multiplex over them instead of paying TCP/TLS setup per request (issue #3283). No React on Rails configuration is required to enable this.
 
 Under standard Puma, the streaming helper's `Sync {}` block creates a per-request scheduler. The async-http client is cleaned up when that streaming response ends, so connection reuse does not persist across consecutive Rails requests. The benefit is still meaningful inside a single streamed response: renderer calls in that response can share the same client lifecycle and `renderer_http_pool_size` still bounds concurrent HTTP/2 streams.
 
-`config.renderer_http_keep_alive_timeout` is **deprecated** and ignored: the async-http adapter manages connection lifecycle automatically (connections are reused within the scheduler and cleaned up when it ends). Setting it to a non-`nil` value logs a deprecation warning; setting it to `nil` is silent.
+`config.renderer_http_keep_alive_timeout` is **deprecated** and ignored: the async-http adapter manages connection lifecycle automatically (connections are reused within the scheduler and cleaned up when it ends). Setting it to a non-`nil` value logs a deprecation warning; `nil` is accepted silently.
 
 To confirm reuse, compare before/after `responseEnd` timing and streamed RSC performance marks, and trace renderer sockets when you need to distinguish long-lived scheduler reuse from standard Puma's per-request scheduler cleanup.
 

docs/pro/updating.md

@@ -401,13 +401,14 @@ Before upgrading:
 - Expect renderer connection drops to surface immediately as `ReactOnRailsPro::Error`/connection failures. HTTPX
   previously performed one implicit transport retry for some connection drops; the async-http adapter uses
   `retries: 0` and leaves retry policy to the existing bundle-upload retry loop and caller behavior.
-- Run the node renderer client from the normal Rails request path. Async Rails servers or middleware should call the
-  renderer from inside the request's running scheduler/task context so the async-http client can use scheduler-scoped
-  connection reuse. Avoid invoking renderer requests from a scheduler-only context that lacks an `Async::Task.current?`
-  task; that path may still fall back to a nested reactor.
+- Run the node renderer client from the normal Rails request path. Async Rails servers (Falcon, Puma with an async
+  scheduler) are supported: the async-http client uses scheduler-scoped connection reuse automatically. Middleware
+  should call the renderer from inside the request's running scheduler/task context. Avoid invoking renderer requests
+  from a scheduler-only context that lacks an `Async::Task.current?` task; that path may still fall back to a nested
+  reactor.
 - `config.renderer_http_keep_alive_timeout` remains accepted for compatibility, but it has no effect because
   async-http manages connection lifecycle through its scheduler-scoped clients and ephemeral request clients. Setting
-  it now emits a deprecation warning.
+  it to a non-`nil` value emits a deprecation warning; `nil` is accepted silently.
 
 #### Upgrading to 16.4.0 or later
 

llms-full-pro.txt

@@ -602,13 +602,14 @@ Before upgrading:
 - Expect renderer connection drops to surface immediately as `ReactOnRailsPro::Error`/connection failures. HTTPX
   previously performed one implicit transport retry for some connection drops; the async-http adapter uses
   `retries: 0` and leaves retry policy to the existing bundle-upload retry loop and caller behavior.
-- Run the node renderer client from the normal Rails request path. Async Rails servers or middleware should call the
-  renderer from inside the request's running scheduler/task context so the async-http client can use scheduler-scoped
-  connection reuse. Avoid invoking renderer requests from a scheduler-only context that lacks an `Async::Task.current?`
-  task; that path may still fall back to a nested reactor.
+- Run the node renderer client from the normal Rails request path. Async Rails servers (Falcon, Puma with an async
+  scheduler) are supported: the async-http client uses scheduler-scoped connection reuse automatically. Middleware
+  should call the renderer from inside the request's running scheduler/task context. Avoid invoking renderer requests
+  from a scheduler-only context that lacks an `Async::Task.current?` task; that path may still fall back to a nested
+  reactor.
 - `config.renderer_http_keep_alive_timeout` remains accepted for compatibility, but it has no effect because
   async-http manages connection lifecycle through its scheduler-scoped clients and ephemeral request clients. Setting
-  it now emits a deprecation warning.
+  it to a non-`nil` value emits a deprecation warning; `nil` is accepted silently.
 
 #### Upgrading to 16.4.0 or later
 

llms-full.txt

@@ -18205,13 +18205,13 @@ Guidance:
 - Account for your Rails concurrency: with many Puma threads/workers all streaming, a renderer with only one or two workers becomes the bottleneck. Scale `workersCount` (and renderer replicas) to your real concurrent streamed-render load.
 - Raise `ssr_timeout` for long-running streamed responses — it is the socket idle timeout for the streaming connection. It fires when the renderer sends no data for `ssr_timeout` seconds, not when the total response duration exceeds that value.
 
-### 3. Rails ↔ renderer keep-alive (already on for streaming)
+### 3. Rails ↔ renderer keep-alive (persistent on Falcon/async scheduler; per-request on standard Puma)
 
 Connection reuse is automatic when the renderer request runs under a long-lived `Fiber.scheduler`, such as Falcon or Puma configured with an async scheduler. In that setup, the async-http client is stored on the scheduler and reused across streaming requests, so HTTP/2 connections stay alive and renders multiplex over them instead of paying TCP/TLS setup per request (issue #3283). No React on Rails configuration is required to enable this.
 
 Under standard Puma, the streaming helper's `Sync {}` block creates a per-request scheduler. The async-http client is cleaned up when that streaming response ends, so connection reuse does not persist across consecutive Rails requests. The benefit is still meaningful inside a single streamed response: renderer calls in that response can share the same client lifecycle and `renderer_http_pool_size` still bounds concurrent HTTP/2 streams.
 
-`config.renderer_http_keep_alive_timeout` is **deprecated** and ignored: the async-http adapter manages connection lifecycle automatically (connections are reused within the scheduler and cleaned up when it ends). Setting it to a non-`nil` value logs a deprecation warning; setting it to `nil` is silent.
+`config.renderer_http_keep_alive_timeout` is **deprecated** and ignored: the async-http adapter manages connection lifecycle automatically (connections are reused within the scheduler and cleaned up when it ends). Setting it to a non-`nil` value logs a deprecation warning; `nil` is accepted silently.
 
 To confirm reuse, compare before/after `responseEnd` timing and streamed RSC performance marks, and trace renderer sockets when you need to distinguish long-lived scheduler reuse from standard Puma's per-request scheduler cleanup.