Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[go-fan] Go Module Review: github.com/tetratelabs/wazero

Closed
  • Is something wrong?
#13,622 0 comments 1 reaction 2 assignees View on GitHub

Maintainers usually reply within 1 day

@lpcox is already working on this.

Since Sep 22, 2026.

  • #13637 by @copilot-swe-agent — closed without merging

Assessment

This issue has not been assessed yet.

Description

go-fan module-review

🐹 Go Fan Report: wazero

Module Overview

wazero is a zero-dependency WebAssembly runtime for Go. It supports both a Compiler (AOT/JIT-like) engine on amd64/arm64 and a pure-Go Interpreter engine on other architectures, and implements WASI Preview 1 for guest sandboxing.

Current Usage in gh-aw

The gateway uses wazero to sandbox third-party WASM guards (internal/guard/), which label agents/resources/responses via exported guest functions (label_agent, label_resource, label_response).

  • Files: 6 files (wasm_lifecycle.go, wasm_exec.go, plus tests: wasm_test.go, wasm_config_test.go, wasm_new_options_coverage_test.go, wasm_testruntime_test.go)
  • Key APIs Used:
    • wazero.NewRuntimeConfig() + WithCloseOnContextDone(true), WithMemoryLimitPages(512) (32 MiB cap), WithDebugInfoEnabled(...) gated on debug logging
    • wazero.NewCompilationCache() / NewCompilationCacheWithDir(dir) — a process-level shared compilation cache with mutex-guarded hot-swap (ConfigureGlobalCompilationCache)
    • wasi_snapshot_preview1.Instantiate(ctx, runtime) for WASI support
    • runtime.NewHostModuleBuilder(...).NewFunctionBuilder().WithGoModuleFunction(...) to expose call_backend and host_log host functions to guests
    • runtime.InstantiateWithConfig(ctx, wasmBytes, moduleConfig) with wazero.NewModuleConfig().WithStartFunctions() (suppressing _start), isolated stdin, and captured stdout/stderr
    • module.ExportedFunction(...) lookups with explicit signature validation and a helpful TinyGo-vs-stdlib-Go compile hint on failure
    • Manual adaptive-buffer protocol (4MB→16MB growth, -2 return code convention) for guest↔host data exchange, with WASM trap detection that permanently marks a guard "failed" to avoid using corrupted module state

Research Findings

The version pinned in go.mod (v1.12.0) is the latest tagged release — go list -m -u and the GitHub tags API both confirm no newer tag exists (v1.12.0, published 2026-05-29, is current HEAD of tags).

Recent Updates
  • v1.12.0 (current): Extended Constant Expressions, exception handling, typed references (Wasm 3.0 progress), non-blocking I/O on custom files; several bug fixes (fd_prestat_get overflow, i32 masking, start-function/import errors).
  • v1.11.0: Added golang.org/x/sys as wazero's first go.mod dependency; requires Go 1.24+.
Best Practices
  • Maintainers recommend wazero.NewRuntimeConfig() (auto-selects Compiler vs Interpreter) over pinning NewRuntimeConfigCompiler() for portability — the project already documents and follows this exactly (see the well-written doc comment above newGuardRuntimeConfig).
  • Sharing a single wazero.CompilationCache across runtime instances to avoid redundant JIT compilation — already implemented via globalCompilationCache.
  • Using WithCloseOnContextDone(true) for guaranteed cleanup on context cancellation — already implemented.

Improvement Opportunities

🏃 Quick Wins
  • None identified — the wazero integration is already tight and well-documented. WithDebugInfoEnabled gated on logWasm.Enabled() is a nice touch that most consumers miss (avoids DWARF parsing overhead for untrusted guest binaries in production).
✨ Feature Opportunities
  • The custom growable-buffer host/guest data exchange protocol (callWasmFunction's manual 4MB→16MB retry loop) predates wazero's newer typed-reference/exception-handling additions in v1.12.0. These new features are guest-language-level (compiler-emitted) and wouldn't simplify the existing buffer protocol, but are worth tracking if the guard ABI is ever revisited for a v2 (e.g., using wasm exceptions instead of the -2/return-code error convention).
📐 Best Practice Alignment
  • Fully aligned. The code already follows wazero's own recommended patterns for engine auto-selection, cache sharing, WASI instantiation order, and context-based cleanup.
🔧 General Improvements
  • Consider periodically re-checking wazero's RATIONALE.md/CHANGELOG for the Wasm 3.0 rollout (exception handling, typed refs) in case future guard toolchains (TinyGo) start emitting these features, which could eventually let host functions replace some of the manual error-code conventions with structured wasm traps/exceptions.

Module Summary

Field Value
Module github.com/tetratelabs/wazero
Version v1.12.0
Repository https://github.com/tetratelabs/wazero
Latest Release v1.12.0 (no newer tag available)
Last Reviewed 2026-09-22
Key Features
  • Zero-dependency, pure-Go WebAssembly runtime (Compiler + Interpreter engines)
  • WASI Preview 1 support (wasi_snapshot_preview1)
  • Process-wide compilation caching (in-memory or disk-backed)
  • Host function bridging via NewHostModuleBuilder
  • Memory limiting, context-based lifecycle control, DWARF debug info toggle
References

Recommendations

  1. No dependency bump needed — v1.12.0 is current.
  2. No code changes recommended this cycle; usage already reflects wazero maintainer best practices for runtime config, caching, and WASI setup.
  3. Keep an eye on wazero's exception-handling/typed-reference work landing in guest toolchains, as it could eventually inform a simpler guard ABI.

Next Steps

  • Re-review after the next wazero tagged release, or if TinyGo guard toolchain support changes (Go version compatibility gate noted in code comments).

Generated by Go Fan

Generated by Go Fan · copilot · auto · 72.3 AIC · ⊞ 12K · ◷

  • expires on Sep 29, 2026, 7:24 AM UTC
Dominant language
Go
Stars
176
Forks
51
Avg merge
6h 40m
Merged PRs (30d)
258

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-aw-mcpg

All issues in github/gh-aw-mcpg

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.