WebAssembly Component Model & WASI 0.2 Studio

package example:edge-service@0.2.0;

interface types {
  record request-payload {
    client-ip: string,
    user-agent: string,
    risk-score: f32,
  }
}

world edge-worker {
  import wasi:http/outgoing-handler@0.2.0;
  import wasi:keyvalue/store@0.2.0;
  
  export wasi:http/incoming-handler@0.2.0;
}

1. Missing 'cabi_realloc' Export Causing Fatal Host Traps

When passing variable-length types (like strings or byte arrays) into a component, the host invokes the component's exported cabi_realloc function to allocate memory. If a custom toolchain fails to export cabi_realloc, the runtime immediately panics with a fatal unhandled trap.

2. Unintended Linear Memory Bloat Across Multiple Composed Runtimes

Composing a Rust component with a Python component (via Componentize-Py) embeds the entire CPython interpreter binary and garbage collector inside the Wasm binary (~15-20 MB). Developers assuming all Wasm components are lightweight can be surprised by massive memory consumption at high concurrency.

3. WIT Semantic Version Mismatches During Composition

If Component A expects wasi:http@0.2.0 while Component B was compiled with wasi:http@0.2.0-rc-1, the component composer (wac or wasm-tools compose) strictly refuses to link them. Semantic version constraints on WIT interfaces are exact and non-negotiable.

4. Blocking I/O Deadlocks on Async 'wasi:io/poll'

In WASI 0.2, network streams and subprocess pipes are non-blocking and yield pollable handles. If a component attempts a synchronous spin-loop read without yielding execution via wasi:io/poll.poll, it blocks the host thread and starves other serverless tasks.

5. Premature Resource Handle Dropping

In WIT interfaces, dropping a resource-drop handle before all downstream consumers finish reading triggers an instant host error. Complex pipelines must pass borrowed references (borrow<stream>) instead of owned resources to guarantee lifecycle safety.