What causes "oh no" in windmill-labs/windmill?

Read the actual failure location from the WASM stack trace and fix the violated invariant in the calling code.

oh no

Error message

oh no

What it means

__assert_fail() — the C assert() failure handler — is stubbed in wasm_libc.rs to panic with the unhelpful message "oh no". When an assert() in WASM-compiled code fails, control lands here and the whole execution aborts. The generic message hides which assertion failed.

Source

Thrown at backend/parsers/windmill-parser-csharp/src/wasm_libc.rs:206

    _args: ...
) -> c_int {
    panic!("vsnprintf is not supported");
}

#[no_mangle]
pub extern "C" fn clock_gettime(ptr: usize, new_size: usize) {
    panic!("asdasd");
}

// int snprintf( char* restrict buffer, size_t bufsz, const char* restrict format, ... );
#[no_mangle]
pub extern "C" fn snprintf() {
    panic!("snprintf is not supported");
}

#[no_mangle]
pub extern "C" fn __assert_fail(_: *const i32, _: *const i32, _: *const i32, _: *const i32) {
    panic!("oh no");
}

View on GitHub (pinned to e474e8803c)

Solutions

Read the actual failure location from the WASM stack trace and fix the violated invariant in the calling code.
Build the native component with NDEBUG (release) so asserts are compiled out in WASM.
Improve the shim: implement __assert_fail in wasm_libc.rs to console_log the file/line/expression before panicking so future failures are diagnosable.
Fix the upstream condition that fails (often a null pointer or unsupported input reaching native glue).

Example fix

// before
pub extern "C" fn __assert_fail(_: *const i32, _: *const i32, _: *const i32, _: *const i32) {
    panic!("oh no");
}
// after
pub extern "C" fn __assert_fail(f: *const i32, l: *const i32, _: *const i32, e: *const i32) {
    panic!("assert failed: {}:{}:{}", read_cstr(f), read_cstr(l), read_cstr(e));
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
  runInWasmParser(code);
} catch (e) {
  if (String(e?.message ?? e) === "oh no") {
    // generic __assert_fail stub message: a C assert() failed in wasm
    console.error("A C-level assert failed inside the wasm runtime; check the stack trace for file/line.");
  } else {
    throw e;
  }
}

Prevention

Build native wasm components with NDEBUG so asserts compile out.
Improve the __assert_fail shim to log file/line/expression before panicking.
Treat "oh no" in logs as a failed C assert and inspect the wasm backtrace.
Validate inputs crossing into native glue to avoid tripping invariants.

When it happens

Trigger: A C assert(cond) compiled into the WASM module evaluates false, so the compiler-emitted call to __assert_fail(file, line, func, expr) fires.

Common situations: Debug-build native dependencies with asserts enabled running under the WASM parser; invariants violated in libc/glue code (null pointers, unexpected enum values, corrupted state); release flags changed so NDEBUG is no longer defined.

Related errors

AI-assisted analysis of windmill-labs/windmill@e474e8803c (2026-09-03). Data as JSON: /api/errors/c4925253d94b1745. Report an issue: GitHub.