ruvnet/ruflo · error

batchProcess requires WASM kernel

Error message

batchProcess requires WASM kernel

What it means

batchProcess() is the only kernel operation with no pure-JS equivalent: the fallback stub throws unconditionally because batched envelope processing is only worth implementing in the accelerated WASM path. Unlike verifyChain/scanSecrets/detectDestructive, there is no redirected implementation — you must either have WASM or do the operations sequentially yourself.

Source

Thrown at v3/@claude-flow/guidance/src/wasm-kernel.ts:183

      hmacSha256: jsHmacSha256,
      contentHash: jsContentHash,
      signEnvelope: jsHmacSha256,
      verifyChain: () => {
        // Chain verification requires full envelope parsing — not implemented
        // in JS fallback because the ProofChain class already does it.
        throw new Error('verifyChain not available in JS fallback; use ProofChain.verifyChain()');
      },

      scanSecrets: (): string[] => {
        // Gate scanning in JS fallback defers to EnforcementGates class
        throw new Error('scanSecrets not available in JS fallback; use EnforcementGates');
      },
      detectDestructive: (): string | null => {
        throw new Error('detectDestructive not available in JS fallback; use EnforcementGates');
      },

      batchProcess: (): BatchResult[] => {
        throw new Error('batchProcess requires WASM kernel');
      },
    };
  }

  return kernelInstance;
}

/**
 * Check if the WASM kernel is available without initializing it.
 */
export function isWasmAvailable(): boolean {
  return getKernel().available;
}

/**
 * Reset the kernel instance (for testing).
 */
export function resetKernel(): void {

View on GitHub (pinned to fa13ee4ad6)

Solutions

  1. Check isWasmAvailable() before batching; if false, execute each operation individually via the JS primitives (sha256, hmacSha256, contentHash are available on the fallback)
  2. Fix WASM loading so the batch path exists: verify the .wasm file is emitted and resolvable at runtime
  3. Expose batchProcess only in deployments you have verified can instantiate the WASM kernel

Example fix

// before
const results = getKernel().batchProcess(ops); // throws without WASM

// after
const kernel = getKernel();
const results = kernel.available
  ? kernel.batchProcess(ops)
  : ops.map((op) => runOpWithJsPrimitives(op, kernel)); // sha256/contentHash still work
Defensive patterns

Strategy: type-guard

Validate before calling

const kernel = getKernel();
const results = kernel.available
  ? kernel.batchProcess(ops)
  : ops.map((op) => runWithJsPrimitives(op, kernel)); // sha256/hmac/contentHash still work on fallback

Type guard

function canBatch(k: WasmKernel): k is WasmKernel & { available: true } {
  return k.available === true; // batchProcess has NO JS fallback implementation
}

Try / catch

try {
  results = kernel.batchProcess(ops);
} catch (e) {
  if (e instanceof Error && e.message.includes('requires WASM kernel')) {
    results = ops.map((op) => runWithJsPrimitives(op, kernel)); // graceful degradation
  } else {
    throw e;
  }
}

Prevention

When it happens

Trigger: Calling getKernel().batchProcess(ops) when the WASM kernel is unavailable — the JS fallback's batchProcess stub throws on invocation regardless of arguments.

Common situations: Environments where the .wasm asset fails to load (bundler misconfiguration, runtime without WebAssembly, CSP); code that assumed batch acceleration is universal; perf-sensitive paths accidentally run on the fallback.

Related errors

AI-assisted analysis of ruvnet/ruflo@fa13ee4ad6 (2026-08-18). Data as JSON: /api/errors/2c8a101546aea48c. Report an issue: GitHub.