moeru-ai/airi · info · Error

Node worker transport is not available in web runtime.

Error message

Node worker transport is not available in web runtime.

What it means

Thrown by `createPluginContext()` in the web runtime when `transport.kind === 'node-worker'`. Node Worker threads are not available in a browser environment, so the web runtime explicitly rejects this transport. This is a hard environment mismatch, not a missing feature.

Source

Thrown at packages/plugin-sdk/src/plugin-host/runtimes/web/index.ts:32

 * Use when:
 * - Bootstrapping a web runtime extension session
 *
 * Expects:
 * - `transport` describes a transport supported by the web runtime
 *
 * Returns:
 * - A web-compatible Eventa context, or throws if the transport is not implemented
 */
export function createPluginContext(transport: PluginTransport): EventContext<any, any> {
  switch (transport.kind) {
    case 'in-memory':
      return createContext()
    case 'websocket':
      throw new Error('WebSocket transport is not implemented for web runtime yet.')
    case 'web-worker':
      throw new Error('Web worker transport is not implemented yet.')
    case 'node-worker':
      throw new Error('Node worker transport is not available in web runtime.')
    case 'electron':
      throw new Error('Electron transport is not available in web runtime.')
    default:
      throw new Error('Unknown plugin transport kind.')
  }
}

View on GitHub (pinned to 27111382b4)

Solutions

Use `createPluginContext({ kind: 'in-memory' })` in browser code; reserve `node-worker` for the Node runtime.
Condition transport selection on the detected runtime/environment rather than hardcoding it.
Audit build config (Vite entries, externalization) to ensure Node-only plugin host code is not bundled into the web target.
If you genuinely need Node Worker threads, run that plugin host in a Node process, not the web runtime.

Example fix

// before
const ctx = createPluginContext({ kind: 'node-worker', workerPath })

// after
const ctx = createPluginContext({ kind: 'in-memory' })

Defensive patterns

Strategy: type-guard

Validate before calling

const runtime = detectRuntime()
const kind = runtime === 'node' ? 'node-worker' : 'in-memory'
const ctx = createPluginContext({ kind })

Type guard

function isBrowserRuntime(): boolean {
  return typeof window !== 'undefined' && typeof (window as any).process === 'undefined'
}

function isWebSafeTransport(t: PluginTransport): boolean {
  return t.kind === 'in-memory'
}

Try / catch

try {
  ctx = createPluginContext(transport)
} catch (e) {
  if (e instanceof Error && /not available in web runtime/i.test(e.message)) {
    ctx = createPluginContext({ kind: 'in-memory' })
  } else throw e
}

Prevention

Never pass node-worker transport to the web runtime; reserve it for Node entrypoints.
Condition transport selection on runtime detection (browser vs node).
Audit Vite/externalization config so Node-only plugin host code stays out of the browser bundle.
Use environment-aware config objects instead of a single shared preset.

When it happens

Trigger: Selecting the `node-worker` transport kind while constructing a plugin context in the web runtime (browser bundle). Happens when Node-targeted plugin host config is loaded in a browser entrypoint.

Common situations: Sharing a plugin host configuration object across Node and web builds without conditioning the transport on environment; SSR or isomorphic code paths that accidentally execute the web runtime config server-style; build misconfiguration that ships the Node plugin host to the browser bundle.

Related errors

AI-assisted analysis of moeru-ai/airi@27111382b4 (2026-08-12). Data as JSON: /api/errors/1265623ebd555904. Report an issue: GitHub.