docs(snapstart): correct the after-restore hook deadline

The hook's bound was documented as the function timeout. It isn't: Lambda
allows the whole Restore phase 10 seconds — runtime load, the after-restore
hook, and the readiness check that follows it all share that window — and
overrunning it fails the restore with Lambda.SnapStartTimeoutException
however long the function timeout is.

Behavior is unchanged (the adapter still sets no deadline of its own, since
it cannot know its share of the window), but a reader budgeting a slow drain
against the wrong number would have been surprised at restore time. Also
notes that an AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS above 10s cannot take
effect on a restore, since Lambda times the phase out first.

Author: bnusunny

CHANGELOG.md

@@ -7,7 +7,8 @@
   (before checkpoint) and `AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH` (after restore) —
   so it can drain and re-establish connections. A non-2xx response or a connection
   failure fails the corresponding SnapStart phase; the adapter sets no deadline of its
-  own, and the after-restore hook must complete within your function timeout. After
+  own, and the after-restore hook must complete within Lambda's 10-second `Restore`
+  phase limit (which it shares with the readiness check that follows it). After
   restore the adapter refreshes its own HTTP client and re-runs the readiness check
   before admitting traffic, and it rejects external traffic to the hook paths with 403.
   - The crate now stops publishing to crates.io (`publish = false`): Lambda Web

README.md

@@ -96,15 +96,20 @@ Each hook is an empty `POST`; your application must respond with a `2xx` status.
 A non-`2xx` response or a connection failure fails the SnapStart phase
 (initialization for the before-checkpoint hook, restore for the after-restore hook)
 instead of serving traffic against an improperly prepared application. The adapter
-does not impose its own deadline on a hook — Lambda bounds both phases, and the
-after-restore hook in particular must finish within your function timeout.
+does not impose its own deadline on a hook — Lambda bounds both phases. Note that
+Lambda allows the whole `Restore` phase only
+[10 seconds](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-troubleshooting.html),
+not your function timeout: the after-restore hook and the readiness check that follows
+it share that window, and overrunning it fails the restore with
+`Lambda.SnapStartTimeoutException`.
 
 After restore, the adapter also automatically refreshes its own HTTP connection
 to your application, so it never reuses a connection captured in the snapshot, and
 then re-runs the readiness check before admitting traffic. By default this wait is
 unbounded; set `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` (fractional seconds allowed)
 to bound it, in which case a restore whose application does not report ready within
-that timeout fails.
+that timeout fails. A value above the 10-second `Restore` limit cannot take effect on
+a restore — Lambda times the phase out first.
 
 > These hook paths are control-plane operations. External requests (via API
 > Gateway or ALB) that target a configured hook path receive `403 Forbidden` and

docs/guide/src/features/snapstart.md

@@ -21,7 +21,7 @@ The adapter always registers for the SnapStart lifecycle; the Lambda runtime inv
 
 > **Note:** `AWS_LWA_ASYNC_INIT` is ignored under SnapStart (and under Provisioned Concurrency). It works around the short initialization limit for on-demand cold starts by reporting init complete before the application is ready; neither of those environments has that limit, and finishing early would snapshot — or serve — a half-initialized application. The adapter logs a warning when it ignores the setting.
 
-Each hook is an empty `POST`, and your application must respond with a `2xx` status. A non-`2xx` response or a connection failure fails the SnapStart phase — initialization for the before-checkpoint hook, restore for the after-restore hook — rather than serving traffic against an improperly prepared application. The adapter does not impose its own deadline on a hook: Lambda already bounds both phases, and the after-restore hook in particular must complete within your function timeout, so keep that in mind when a hook does slow work such as draining a large connection pool. The final readiness check runs on every restore (whether or not an after-restore path is configured). By default this readiness wait is unbounded; set `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` (fractional seconds allowed, e.g. `0.5`) to bound it, in which case a restore whose application does not report ready within that timeout fails. The same variable also bounds the initial cold-start readiness check, which under SnapStart is what guarantees the application is ready before the snapshot: when set and the application does not report ready within the timeout, initialization fails (the Lambda runtime never starts) rather than snapshotting or serving an app that never came up.
+Each hook is an empty `POST`, and your application must respond with a `2xx` status. A non-`2xx` response or a connection failure fails the SnapStart phase — initialization for the before-checkpoint hook, restore for the after-restore hook — rather than serving traffic against an improperly prepared application. The adapter does not impose its own deadline on a hook: Lambda already bounds both phases. The bound on the after-restore hook is not your function timeout — Lambda allows the whole `Restore` phase only [10 seconds](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-troubleshooting.html), shared by the runtime load, the after-restore hook, and the readiness check that follows it, and overrunning it fails the restore with `Lambda.SnapStartTimeoutException`. Keep that in mind when a hook does slow work such as draining a large connection pool. The final readiness check runs on every restore (whether or not an after-restore path is configured). By default this readiness wait is unbounded; set `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` (fractional seconds allowed, e.g. `0.5`) to bound it, in which case a restore whose application does not report ready within that timeout fails — a value above the 10-second `Restore` limit cannot take effect on a restore, since Lambda times the phase out first. The same variable also bounds the initial cold-start readiness check, which under SnapStart is what guarantees the application is ready before the snapshot: when set and the application does not report ready within the timeout, initialization fails (the Lambda runtime never starts) rather than snapshotting or serving an app that never came up.
 
 ## Why you need the hooks
 

src/snapstart.rs

@@ -93,11 +93,13 @@ impl SnapStartHooks {
     /// POSTs an empty body to `domain + path`. A non-2xx response or a transport error
     /// fails the SnapStart phase.
     ///
-    /// Deliberately unbounded: Lambda bounds both phases already (the init budget, and
-    /// the function timeout for the after-restore hook). A fixed adapter-side cap was
-    /// unreachable for one phase and killed legitimate slow drains in the other. A cap
-    /// derived from the function timeout isn't possible — Lambda exposes no timeout
-    /// env var and there is no invocation context here.
+    /// Deliberately unbounded: Lambda bounds both phases already — the init budget for
+    /// before-checkpoint, and the 10-second `Restore` phase limit for after-restore
+    /// (`Lambda.SnapStartTimeoutException`), which is NOT the function timeout. That
+    /// 10 seconds also covers runtime load and the readiness check that follows the
+    /// hook POST, so the adapter cannot know its own share of it; overrunning fails the
+    /// restore either way. A fixed adapter-side cap was unreachable in one phase and
+    /// killed legitimate slow drains in the other.
     async fn post_hook(client: &Client<HttpConnector, Body>, domain: &Url, path: &str) -> Result<(), Error> {
         let mut url = domain.clone();
         url.set_path(path);