Skip to main content
← Back

Custom Interfaces, Distributed RPC Errors & the Wasm Component Model

The February 26, 2025 wasmCloud community call digs into the Wasm component model and the realities of distributed computing. Brooks Townsend demos a proposal for handling transport-level failures in custom interfaces — a well-known RPC error type, defined in WIT, that lets a WebAssembly component gracefully catch errors like a missing link, an unreachable target, or a disconnected NATS, instead of trapping. The call also previews KubeCon EU 2025, walks through wasmCloud's new auto-generated release notes driven by conventional commits, and covers community questions on built-in providers, wasi:http, and a community-built Cron capability provider.

Key Takeaways​

  • In wasmCloud, any WIT interface that isn't a well-known one (like wasi:http, wasi:io, wasmCloud messaging, or wasmCloud Postgres) is a custom interface — wasmCloud polyfills it at runtime and routes the invocation over NATS to a component or capability provider that implements the other end
  • Today wasmCloud does not surface transport-level errors from those distributed RPC calls — if NATS is disconnected or the target isn't running, the component traps or panics rather than getting a recoverable error
  • Brooks' proposal: distribute a well-known RPC error type as part of wasmCloud's WIT, so a custom function returning result<T, rpc-error> can opt in and handle platform-level failures (no link, no target, transport timeout) with normal language error handling — enabling retries and exponential backoff
  • The design deliberately preserves component composition: when components are composed with wasm-tools compose, the rpc-error variant is never surfaced; it only appears when running in wasmCloud and the distributed invocation actually fails. Brooks plans to discuss it with Roman on the wRPC side before any PR lands
  • KubeCon EU 2025 (London, first week of April) is coming fast — wasmCloud maintainers have talks on wasmCloud's journey to WebAssembly standards, the CNCF TAG Runtime, and SPIFFE/workload identity for WebAssembly; community members are encouraged to come by the booth and to demo their work (live or via pre-recorded video)
  • wasmCloud's auto-generated release notes have landed: a conventional-commit bot labels PRs by scope and impact, and GitHub rolls them up into new-features / bug-fixes / breaking-changes sections — making the PR title the load-bearing piece for clean release notes
  • Built-in providers (HTTP server, messaging) are treated exactly like discrete capability providers — the only difference is the image reference (wasmcloud+builtin://...); wstd/wasi:http is mature enough to start updating examples, and a community-built Cron capability provider should follow the Postgres release pattern (implement locally, then release the WIT and provider together)

Chapters​

Meeting Notes​

Demo & Discussion: Custom Interfaces and Failures in Distributed RPC​

Beyond the well-known interfaces wasmCloud ships — like wasi:http, wasi:io, wasmCloud messaging, and wasmCloud Postgres — you can define your own custom interfaces in WIT. A custom interface expresses a contract that a WebAssembly component wants to call or implement. When you start that component, wasmCloud creates a polyfill: instead of the runtime panicking on an unknown function, it sends the invocation over NATS to whatever component or capability provider implements the other end. This is exactly how you build your own custom capability providers today.

There's an important piece wasmCloud doesn't currently surface: transport-level errors in that distributed RPC call. If you invoke another component over a custom function and you're temporarily disconnected from NATS, or the target isn't running, the call fails — represented as a trap or panic depending on the language — and there's no mechanism to hand that error back to you so you can recover. This is partly by design: wasmCloud wants you writing business logic without thinking about load balancing or connectivity. But, as Brooks put it, "we can't ignore those aspects of a possibly failing distributed system."

Brooks' proposal is to distribute a well-known RPC error type as part of wasmCloud's WIT. A custom function can opt in by returning result<T, rpc-error>, where rpc-error is a record wasmCloud knows about, with variants for the different places an invocation can fail — a link that doesn't exist (the operator hasn't permitted the component to invoke that interface), a target that isn't running, or a transport/wRPC failure. With that in place, the component can use ordinary language-level error handling to catch the failure, return a meaningful HTTP 500, retry, or apply exponential backoff.

Demo: Error Handling in Action​

Brooks ran a modified hello world component with a custom function, starting a wasmCloud host with the built-in HTTP server and a one-second component execution timeout. Three failure cases that previously couldn't be handled now surface cleanly to the component:

  • No link / no target: with no component implementing the custom call, the RPC doesn't resolve to anything. Instead of panicking, the component receives an error saying it isn't allowed to invoke that instance — so a developer who knows a custom interface might fail can plan a backup path.
  • Link exists but target isn't running: the underlying "failed to flush outgoing stream" error becomes a recoverable signal that the target probably isn't connected, so the component can wait and retry.
  • NATS goes down entirely: using the built-in HTTP server (which doesn't transmit the request over NATS), Brooks killed NATS, and after the one-second timeout the component returned a "transmitting data has timed out" error rather than hanging. Bring NATS back and wasmCloud reconnects.

A key design constraint: this must preserve component composition. Across a component boundary — when you compose with wasm-tools compose — the result<T, rpc-error> is immediately unwrapped to the ok value; the rpc-error variant only surfaces when running inside wasmCloud and a real invocation fails. So adopting it never precludes optimizing your application by composing components together later. Brooks plans to socialize the idea with Roman on the wRPC side and in Slack before any PR, since the error type may belong in wRPC rather than wasmCloud.

Road to KubeCon EU 2025​

KubeCon + CloudNativeCon EU lands the first week of April in London, with Wasm I/O in Barcelona right before it. The Wasm track is packed: CNCF TAG Runtime efforts, Brooks on wasmCloud's journey to WebAssembly standards and a retrospective on the project, and Jonas and Colin on SPIFFE and workload identity for WebAssembly workloads. If you'll be in Barcelona or London, the team would love to meet you at the booth. With the pre-conference crunch, the next few community meetings may be shorter — and everyone is welcome to fill a demo slot, live or with a pre-recorded video. (See the wasmCloud at KubeCon + CloudNativeCon EU 2025 preview for the full schedule.)

Auto-Generated Release Notes and Conventional Commits​

The labeling work the team previewed in earlier calls has landed in main. When you open a PR into the wasmCloud repo, a conventional-commit bot parses the commit message to confirm it's conventional and labels the PR with its scope (e.g. host) and whether it's a feature, a fix, or a breaking change. When releases are cut — like 1.6.2 — GitHub auto-generates release notes with sections for new features, bug fixes, and other changes, with breaking changes pulled to the top. CI churn and dependabot bumps are filtered out for cleaner notes. The one thing to watch: the PR title is now load-bearing, because it's what ends up in the generated notes.

Community Q&A​

  • Built-in vs external providers (ossfellow): the built-in HTTP server and messaging providers are treated exactly the same as discrete/binary capability providers — the only difference is the image reference, using the special wasmcloud+builtin://... syntax. Good guidance for anyone building, e.g., a built-in HTTP client.
  • wstd / wasi:http (Colin): the wstd crate and wasi:http are mature enough that wasmCloud examples could start using them directly. Bailey noted the Bytecode Alliance is building out canonical examples (the Rust wasi:http example owns a generic OCI-image build workflow, signing, and a dev container) and welcomes new languages.
  • Cron capability provider (Aditya): implement the capability provider against your local Cron WIT first, prove it out in-repo (just like Postgres did), then release the WIT and provider together once the PR merges — using the Postgres release WIT action for inspiration.

WebAssembly News and Updates​

The big WebAssembly-ecosystem theme of this call is resilience and standards convergence. The custom-interface proposal is fundamentally about making the Wasm component model honest about distributed failure: a typed, well-known error variant that any custom WIT interface can adopt. On the standards front, the maturing wstd crate and wasi:http are ready enough that wasmCloud examples can adopt them, and the Bytecode Alliance is curating canonical, signed, OCI-packaged examples across languages. All of it points toward KubeCon EU 2025, where the CNCF TAG Runtime, WebAssembly standards, and SPIFFE-based workload identity for Wasm are all on the agenda. For ongoing updates, follow the Bytecode Alliance and the WASI subgroup.

What is wasmCloud?​

wasmCloud is a CNCF project that lets you build applications using WebAssembly components and deploy them anywhere — cloud, edge, or Kubernetes clusters. It uses the WebAssembly component model to let you write business logic in any supported language (Rust, Go, Python, TypeScript, C#) while the platform handles capabilities like HTTP, messaging, and key-value storage through a pluggable provider architecture. wasmCloud's reference host is built on Wasmtime, and connects components to providers using a distributed RPC layer over NATS. With built-in OpenTelemetry observability and Kubernetes integration, wasmCloud bridges WebAssembly's portable, sandboxed execution model and production cloud-native infrastructure.

Topic Deep Dive: The Wasm Component Model​

Custom interfaces are the Wasm component model at work in a distributed system. A WIT interface is a typed contract; the component model guarantees that whatever implements the other end honors that contract, regardless of language. wasmCloud takes that one step further by satisfying the contract over the network — polyfilling the call and routing it to a remote component or capability provider via wRPC over NATS. The gap this meeting addresses is that distribution introduces failure modes the component model alone doesn't model: links that don't exist, targets that aren't running, transports that drop. Brooks' well-known rpc-error type extends the component-model contract to make those failures first-class and recoverable — and crucially, it does so without breaking component composition, since the error variant collapses away when components are composed locally with wasm-tools compose. It's a clean demonstration of why typed interfaces matter: you can add resilience semantics to an interface without forcing every consumer to care, and without coupling components to the wasmCloud runtime.

Who Should Watch This​

This call is especially valuable for distributed-systems and platform engineers designing resilient WebAssembly applications, who want to see how transport-level RPC failures could become recoverable (start with the custom-interface demo at 1:56), capability provider authors building custom interfaces and providers — including the Cron provider discussion at 38:15 — and maintainers and contributors interested in conventional-commit-driven, auto-generated release notes (25:28). Anyone planning to attend KubeCon EU 2025 will want the conference preview at 19:58.

Up Next​

The custom-interface RPC error proposal will come back in future calls after Brooks discusses it with Roman on the wRPC side and gathers feedback in the wasmCloud Slack — with possible example use cases like catching RPC errors on the wasmCloud Postgres interface. With KubeCon EU 2025 approaching, expect shorter community meetings and previews of upcoming talks over the next few weeks. The community-built Cron capability provider is in draft and will be reviewed once it works locally.

Get Involved​

wasmCloud is a CNCF project and contributions are welcome. Join the community:

Full Transcript​

Read the complete transcript with speaker labels and timestamps:

Read the full transcript →