Unify HTTP request timeout and Wasm execution deadline

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!

Start by reading related issues #3609 and #3610, especially the Wasm execution deadline changes. Review the existing timeout behavior across Spin, WASIp2, WASIp3, and WAGI before deciding how the public setting maps to each handler and reuse mode. Done means consistent timeout behavior, documented approximate precision, and coverage for sleeping requests, CPU-bound loops, reuse, concurrency, and worker retirement.