Unify HTTP request timeout and Wasm execution deadline

[carsonfarmer]

What is the version of your Spin CLI?

Spin main / upcoming 4.1.0 pre-release.

What is your suggestion?

Unify the HTTP request timeout and Wasm execution deadline into one public request_timeout setting.

The timeout should represent the maximum time a request may run. Internally, Spin can use the appropriate mechanisms for each handler and reuse mode:

• a request-level timeout for the total wall-clock budget
• Wasmtime epoch interruption for CPU-bound Wasm
• Store::epoch_deadline_async_yield_and_update where reusable instances need cooperative yielding
• worker retirement when a cancelled request cannot safely be reused

This should behave consistently across Spin, WASIp2, WASIp3, and WAGI where supported, without reimplementing HTTP dispatch.

Why would this improve Spin?

PR #3610 adds a Wasm execution deadline alongside the existing HTTP request timeout. Both are useful, but exposing them as separate fields is confusing because users generally want one thing: a maximum amount of time a request may run.

A single public setting would make the API easier to understand while allowing each handler implementation to use the correct internal mechanism. It should also make timeout behavior consistent between single-use and reused instances.

The implementation should document that timeout precision is approximate because it depends on epoch configuration and host scheduling.

Suggested tests include sleeping requests, CPU-bound loops, reused instances, concurrent requests, and ensuring timed-out workers are not incorrectly reused.

Related: #3609 and #3610.

Are you willing to submit PRs to contribute to this feature or improvement?

• Yes, I am willing to implement it. Though I should point out, I could use help with the design!

[dicej]

worker retirement when a cancelled request cannot safely be reused

This should already mostly be handled in https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-http/src/handler.rs; see https://docs.rs/wasmtime-wasi-http/latest/wasmtime_wasi_http/handler/trait.WorkerState.html#tymethod.on_request_start for details. The key to making that effective in Spin will be to combine it with Store::epoch_deadline_async_yield_and_update to ensure Wasmtime yields frequently enough to allow wasmtime_wasi_http::handler to promptly enforce timeouts.

As the many comments in handler.rs attest, the combination of concurrent instance reuse, request timeouts, and epoch interruption is very non-trivial. I'm happy to discuss the details (e.g. asynchronously on GitHub or synchronously on e.g. the CNCF Slack or BA Zulip.

Thanks for looking into this!