What causes "fdopen is not supported" in windmill-labs/windmill?

Prevent the runtime from calling fdopen by configuring stream initialization off in the WASM build.

fdopen is not supported

Error message

fdopen is not supported

What it means

fdopen() is a deliberate panic stub in wasm_libc.rs ("fdopen is not supported"). WASM has no file descriptors, so wrapping one in a FILE* is impossible. Any call to fdopen aborts the WASM execution immediately.

Source

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

#[no_mangle]
pub unsafe extern "C" fn fprintf(_file: *mut c_void, _format: *const c_void, _args: ...) -> c_int {
    panic!("fprintf is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fputs(_s: *const c_void, _file: *mut c_void) -> c_int {
    panic!("fputs is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fputc(_c: c_int, _file: *mut c_void) -> c_int {
    panic!("fputc is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fdopen(_fd: c_int, _mode: *const c_void) -> *mut c_void {
    panic!("fdopen is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fclose(_file: *mut c_void) -> c_int {
    panic!("fclose is not supported");
}

#[no_mangle]
pub unsafe extern "C" fn fwrite(
    _ptr: *const c_void,
    _size: usize,
    _nmemb: usize,
    _stream: *mut c_void,
) -> usize {
    panic!("fwrite is not supported");
}

#[no_mangle]

View on GitHub (pinned to e474e8803c)

Solutions

Prevent the runtime from calling fdopen by configuring stream initialization off in the WASM build.
Stub fdopen to return a null FILE pointer with graceful caller-side failure handling.
Implement a minimal fdopen backed by an in-memory/console sink if callers expect stdout/stderr.
Remove the native dependency that requires fd-based streams.

Example fix

// before
FILE* f = fdopen(1, "w");
// after
// use a host-provided console writer instead of fd-backed streams

Defensive patterns

Strategy: validation

Validate before calling

// Confirm the wasm runtime never opens fd-backed streams at startup:
if (isWasmHost) {
  runtimeConfig.wireStdioFromFds = false; // avoids fdopen(0/1/2)
}

Try / catch

try {
  runInWasmParser(code);
} catch (e) {
  if (String(e?.message ?? e).includes("fdopen is not supported")) {
    console.warn("fdopen is unsupported in wasm; streams must not be built from file descriptors.");
  } else {
    throw e;
  }
}

Prevention

Never open file descriptors in code intended for the wasm host.
Stub fdopen to return null with graceful failure in wasm_libc.rs if callers can handle it.
Avoid native libraries that re-open stdout/stderr from fds.
Document fd-based I/O as unsupported in the parser runtime.

When it happens

Trigger: Runtime or native code calls fdopen(fd, mode) to attach a stdio stream to file descriptor 0/1/2 (classic stdout/stderr bootstrap) or to open a pipe/socket descriptor.

Common situations: Runtime startup code wiring stdout/stderr FILE objects from fds; C libraries opening descriptors for I/O; mono paths that re-open streams.

Related errors

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