Spike: opt-in reusable sandbox mode (Serve::with_max_requests) #856

Description

The 2026-07-05 performance and architecture review proposed an experiment with Fastly's opt-in reusable sandbox mode, citing Serve::new().with_max_requests(). The goal is to learn whether safely retained process state reduces repeated settings parsing, integration-registry and auction-orchestrator construction, signing-key parsing, or regex compilation. This is a spike: neither the performance gain nor the runtime compatibility has been established in this repository.

Today the Fastly entry point handles one FastlyRequest::from_client() in main() and builds app state for that invocation (crates/trusted-server-adapter-fastly/src/main.rs:77-130). build_state() loads settings, compiles an auction plan, and constructs the orchestrator and registry (app.rs:187-231). Existing OnceLock uses should be inventoried to determine which are actually safe and useful across requests.

Experiment

1. Confirm that the cited reusable-sandbox API exists and is supported by the pinned Fastly SDK (fastly = "0.12") and local/production runtimes. Record deployment constraints and an opt-in rollback path. If the API is unavailable, report that result before changing application state.
2. In an isolated opt-in branch/configuration, serve multiple requests in one sandbox. Separate immutable reusable state from per-request identity, consent, request headers, cookies, and mutable auction data. Define how config or signing-key rotation invalidates retained state.
3. Run repeated requests with distinct fictional identities and consent states, including config/key changes where the runtime permits. Assert no cross-request state bleed, stale configuration, or stale signing key.
4. Compare the current one-request mode with reuse at several request limits under the same workload. Record initialization time, total latency (including tail latency), throughput, memory growth, and error rate. Include cold and warm instances and local/runtime limitations.

Expected outcome

A documented go/no-go decision with measured benefit and correctness evidence. Reuse should proceed only if the SDK/runtime support it, privacy boundaries remain intact, rotation semantics are explicit, and operational measurements justify the added lifecycle complexity.

Done when

• API availability and target-runtime behavior for the pinned SDK are documented.
• An opt-in multi-request prototype and rollback path are exercised without changing the default deployment.
• Cross-request isolation and config/key-rotation cases have passing tests or documented blockers.
• Before/after measurements and the go/no-go decision are attached.

Related

• Original review: 2026-07-05 performance and architecture review, wasm item 4; sequencing item 10 of 10.