The WasmEdge has detailed error logging which is not currently hooked up to proxy_wasm::WasmVmIntegration::error call. This means that error details are swallowed by stderr. For example:
[ RUN ] WasmEngines/TestVm.ImportWithMismatchingTypeFailsLink/wasmedge
[2026-05-20 15:21:31.577] [error] instantiation failed: incompatible import type, Code: 0x301
[2026-05-20 15:21:31.577] [error] Mismatched function type. Expected: FuncType {params{i32 , i32} returns{i32}} , Got: FuncType {params{i32 , i32 , i32} returns{i32}}
[2026-05-20 15:21:31.577] [error] When linking module: "env" , function name: "proxy_log"
[2026-05-20 15:21:31.577] [error] At AST node: import description
[2026-05-20 15:21:31.577] [error] At AST node: import section
[2026-05-20 15:21:31.577] [error] At AST node: module
ERROR from integration: Failed to load Wasm module: incompatible import type
test/runtime_test.cc:204: Failure
Value of: host->isErrorLogged("proxy_log")
Actual: false
Expected: true
[ FAILED ] WasmEngines/TestVm.ImportWithMismatchingTypeFailsLink/wasmedge, where GetParam() = "wasmedge" (4 ms)
WasmEdge exposes a singleton callback that can capture log messages like this (WasmEdge_LogSetCallback), however, we still need to figure out how to integrate it with the different WasmVm instances of WasmEdge.
The WasmEdge has detailed error logging which is not currently hooked up to proxy_wasm::WasmVmIntegration::error call. This means that error details are swallowed by stderr. For example:
WasmEdge exposes a singleton callback that can capture log messages like this (WasmEdge_LogSetCallback), however, we still need to figure out how to integrate it with the different WasmVm instances of WasmEdge.