wasmtime / PR #13812 Unify more of the p2/p3 paths in the... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #13812 Unify more of the p2/p3 paths in the...

Wasmtime GitHub notifications bot (Jul 03 2026 at 03:14):

alexcrichton requested dicej for a review on PR #13812.

Wasmtime GitHub notifications bot (Jul 03 2026 at 03:14):

alexcrichton opened PR #13812 from alexcrichton:http-unify to bytecodealliance:main:

This PR takes us further down the road of designing the wasmtime-wasi-http crate in the same manner as the wasmtime-wasi crate which is to say that there's one source-of-truth context/configuration/etc which all WASI impls are derived from. Previously there were separate hooks/contexts for p2/p3 due to historical differences, and this is a refactoring to bring the two together.

The largest part of the refactoring here is the addition of a new wasmtime_wasi_http::Error type which unifies p2/p3 as well as underlying possible errors. This means that host-facing operations now work with this type rather than the raw WIT types.

Some pieces this helps are:

No more duplication of default_send_request

Large boilerplate removal in the handler.rs module

No more duplication of contexts/hooks/etc.

Better centralized documentation for types.

Hosts have an easier time supporting both p2/p3 with a unified error type.

Note that this is currently built on #13810

Wasmtime GitHub notifications bot (Jul 03 2026 at 03:14):

alexcrichton requested wasmtime-wasi-reviewers for a review on PR #13812.

Wasmtime GitHub notifications bot (Jul 03 2026 at 03:14):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13812.

Wasmtime GitHub notifications bot (Jul 03 2026 at 06:01):

github-actions[bot] added the label wasmtime:c-api on PR #13812.

Wasmtime GitHub notifications bot (Jul 06 2026 at 15:56):

:thumbs_up: dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 06 2026 at 15:56):

:speech_balloon: dicej created PR review comment:

I'm a bit surprised to see warn-level logging in a From implementation. What's the rationale?

(same comment applies to p3/conv.rs)

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:22):

alexcrichton updated PR #13812.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:26):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Jul 06 2026 at 16:26):

:speech_balloon: alexcrichton created PR review comment:

This is pseudo-preserving preexisting behavior where this is a copy of this function for example, although it wasn't modeled as From before.

IIRC though the source of this is me asking to add a log here. I'm personally paranoid about dropping error context on the floor as it can create pretty confusing situations downstream, and this was intended to strike a balance of "someone can figure things out if things go wrong" with the representation needs here.

I do agree though it's a bit different being in From vs a freestanding function. Do you have a preference to model this not as From but with an explicit conversion?

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:34):

:memo: dicej submitted PR review.

Wasmtime GitHub notifications bot (Jul 06 2026 at 17:34):

:speech_balloon: dicej created PR review comment:

I don't feel strongly about it, although making it an explicit conversion seems reasonable; most people aren't expecting From/Into to have side effects like logging.