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

Find which code inside the WASM runtime calls clock() and remove or replace it with a supported timing API (e.g. clock_gettime/gettimeofday if implemented).

windmill-labs/windmill · error

clock is not supported

Error message

clock is not supported

What it means

The C# parser crate compiles a minimal libc shim (wasm_libc.rs) so a .NET runtime can run inside WebAssembly. clock() is deliberately stubbed: it immediately panics with "clock is not supported" because the browser/WASM host provides no meaningful process CPU time. Any WASM code path that imports or calls the C `clock()` function hits this panic at runtime.

Source

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

}

/* -------------------------------- wctype.h -------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn iswspace(c: c_int) -> bool {
    char::from_u32(c as u32).map_or(false, |c| c.is_whitespace())
}

#[no_mangle]
pub unsafe extern "C" fn iswalnum(c: c_int) -> bool {
    char::from_u32(c as u32).map_or(false, |c| c.is_alphanumeric())
}

/* --------------------------------- time.h --------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn clock() -> u64 {
    panic!("clock is not supported");
}

/* --------------------------------- ctype.h -------------------------------- */

#[no_mangle]
pub unsafe extern "C" fn isprint(c: c_int) -> bool {
    c >= 32 && c <= 126
}

/* --------------------------------- stdio.h -------------------------------- */

#[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 {

View on GitHub (pinned to e474e8803c)

Solutions

Find which code inside the WASM runtime calls clock() and remove or replace it with a supported timing API (e.g. clock_gettime/gettimeofday if implemented).
Guard the call so it is only made on native hosts, not in the WASM parser environment.
If you control wasm_libc.rs, implement clock() to return a best-effort value (e.g. 0 or a monotonic counter) instead of panicking.
Report/upgrade to a .NET WASM runtime build whose bootstrap avoids clock().

Example fix

// before
let t = clock(); // panics in wasm
// after
let t = std::time::Instant::now(); // or a host-provided monotonic clock

Defensive patterns

Strategy: validation

Validate before calling

// Before running code in the WASM C# parser, avoid host-unsupported libc calls:
if (OperatingSystem.IsBrowser() || isWasmHost)
{
    // never call CPU-time APIs like clock(); use managed time instead
    var elapsed = Stopwatch.GetTimestamp(); // System.Diagnostics.Stopwatch
}

Type guard

function avoidsCpuClockCode(source) {
  return !/\bclock\s*\(/.test(source); // true => safe to run in the wasm host
}

Try / catch

try {
  runInWasmParser(code);
} catch (e) {
  if (String(e?.message ?? e).includes("clock is not supported")) {
    console.warn("CPU-time APIs are unavailable in the wasm C# parser; use managed timing.");
  } else {
    throw e;
  }
}

Prevention

Avoid native/profiling dependencies that call clock() when targeting the WASM parser.
Use managed timing APIs (Stopwatch, DateTime.UtcNow) instead of libc time functions.
Keep a list of unsupported libc symbols for the host and lint native code against them.
If you maintain the shim, prefer returning a benign value over panicking for diagnostic clocks.

When it happens

Trigger: The .NET/WASM runtime executing inside the C# parser calls the libc `clock()` symbol (e.g. mono runtime diagnostics, Environment.TickCount/processor-time probing, or a GC/profiling path requesting CPU time).

Common situations: Running code in the browser-based C# parser that measures CPU time; a .NET runtime build or BCL version that newly imports clock(); using profiling or timing libraries that call clock(2) under the hood.

Related errors

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