Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: aws/aws-lambda-rust-runtime
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: lambda_runtime-v1.2.1
Choose a base ref
...
head repository: aws/aws-lambda-rust-runtime
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: lambda_runtime-v1.3.0
Choose a head ref
  • 2 commits
  • 25 files changed
  • 2 contributors

Commits on Jul 9, 2026

  1. feat: add SnapStart support via SnapStartResource trait (#1150) 

    Implement the SnapStart restore lifecycle so Rust Lambda functions can
participate in SnapStart optimizations when deployed as container images
with custom base images.

Custom logic around the snapshot/restore boundary is expressed by
implementing the CRaC-style `SnapStartResource` trait and registering
instances on the runtime. The trait methods return `BoxFuture` (no
`async-trait` dependency) so the trait stays object-safe as
`dyn SnapStartResource`. The runtime drives the lifecycle internally:

  before_snapshot hooks (LIFO) -> GET /restore/next (blocks until restore)
  -> rebuild RAPID connection pool -> after_restore hooks (FIFO)

Resources use stack ordering: register foundations first; before_snapshot
runs in reverse registration order and after_restore in registration order.

Error handling: a before-snapshot/`/restore/next` failure is reported to
Lambda via POST /init/error; an after_restore failure via POST
/restore/error. Both are propagated outward so the runtime exits via the
normal Result path (no process::exit, so graceful-shutdown handlers still
run). Failures to send the report are logged. When SnapStart is not enabled
the hooks are never invoked.

Connection-pool reset after restore is non-breaking: rather than mutating the
existing `Client`, a new `PooledClient` (with lock-free `OnceLock`-based
`reset_pool()`) and a `RuntimeApiClient` trait are added to the api-client
crate. `lambda_runtime`'s service layer takes a defaulted generic
`C = Client` bounded by the trait and uses `PooledClient` internally; the old
`Client` is frozen at its 1.0.3 shape and deprecated. cargo-semver-checks
confirms all three crates stay non-breaking (api-client is a 1.1.0 minor bump
for the deprecation + additive API).

Changes:
- lambda-runtime-api-client: add `PooledClient` + `RuntimeApiClient` trait +
  `ClientBuilder::build_pooled`; deprecate `Client`/`build`; bump to 1.1.0
- lambda-runtime: add `SnapStartResource` trait, Init/Restore error requests,
  `Runtime::is_snapstart()` and `register_snapstart_resource()`; run the
  restore lifecycle from run()/run_concurrent(); defaulted-generic service
  layer using `PooledClient`; re-export `SnapStartResource` and `BoxFuture`
- lambda-http: add runtime()/runtime_concurrent() and streaming_runtime()
  helpers; re-export `SnapStartResource` and `BoxFuture`
- lambda-extension: use `PooledClient`
- examples: add basic-snapstart and http-snapstart
- tests: request serialization, full restore lifecycle, LIFO/FIFO ordering,
  no-op when not SnapStart, and before/after/restore-next failure paths
    @bnusunny
    bnusunny authored Jul 9, 2026
    Configuration menu
    Copy the full SHA
    094dbf9 View commit details
    Browse the repository at this point in the history

  2. chore: release (#1151)

    @darklight3it
    darklight3it authored Jul 9, 2026
    Configuration menu
    Copy the full SHA
    34e669c View commit details
    Browse the repository at this point in the history
Loading