stablyai/orca · error · Error

Timed out while selecting the IBus Hangul engine

Error message

Timed out while selecting the IBus Hangul engine

What it means

waitForHangulEngine() polls `ibus engine hangul` every 100ms until it succeeds, with a hard 15s deadline. If the daemon stays alive but never accepts the hangul engine selection, the deadline expires and the harness gives up. This indicates the engine is registered but not becoming active — a softer failure than a crash.

Source

Thrown at config/scripts/run-terminal-ibus-hangul-e2e.mjs:112

    if (result.status !== 0) {
      throw new Error(`Failed to configure IBus Hangul ${key}: ${result.stderr.trim()}`)
    }
  }
}

async function waitForHangulEngine(ibusProcess) {
  const deadline = Date.now() + 15_000
  while (Date.now() < deadline) {
    if (ibusProcess.exitCode !== null) {
      throw new Error(`ibus-daemon exited early with code ${ibusProcess.exitCode}`)
    }
    const result = spawnSync('ibus', ['engine', 'hangul'], { stdio: 'pipe' })
    if (result.status === 0) {
      return
    }
    await delay(100)
  }
  throw new Error('Timed out while selecting the IBus Hangul engine')
}

async function runInsideSession(evidenceDir) {
  const ibusLogPath = path.join(evidenceDir, 'ibus-daemon.log')
  const ibusLogFd = openSync(ibusLogPath, 'w')
  const windowManagerLogPath = path.join(evidenceDir, 'xfwm4.log')
  const windowManagerLogFd = openSync(windowManagerLogPath, 'w')
  const evidence = {
    display: process.env.DISPLAY ?? null,
    ibusDaemonPid: null,
    ibusGroupBeforeCleanup: [],
    ibusGroupAfterCleanup: [],
    playwrightPid: null,
    windowManagerPid: null,
    windowManagerGroupAfterCleanup: []
  }
  let ibusProcess
  let windowManagerProcess

View on GitHub (pinned to 1136503c6a)

Solutions

1. Increase the deadline in waitForHangulEngine() only if you have confirmed the engine does eventually activate (log timestamps).
2. Run `ibus list-engine` and confirm hangul appears; run `ibus engine hangul` by hand to see the actual error.
3. Pre-warm the daemon: start ibus-daemon earlier in the session and call `ibus engine hangul` once before the harness runs.
4. Reduce DBus/xvfb contention — close other IBus consumers on the session.

Example fix

// before
const deadline = Date.now() + 15_000
// after (only after confirming slow-but-successful activation)
const deadline = Date.now() + 45_000

// preflight: engine selectable at all
const { spawnSync } = require('node:child_process')
const r = spawnSync('ibus', ['list-engine'], { encoding: 'utf8' })
if (!/hangul/i.test(r.stdout || '')) {
  console.error('hangul engine not registered'); process.exit(1)
}

let lastErr
for (let attempt = 0; attempt < 3; attempt++) {
  try { await waitForHangulEngine(ibusProcess); break }
  catch (err) {
    lastErr = err
    if (/Timed out/.test(String(err))) { await delay(2000); continue }
    throw err
  }
}
if (lastErr) throw lastErr

When it happens

Trigger: ibus-daemon is alive and responding but `ibus engine hangul` keeps returning non-zero for 15 seconds — e.g. the hangul engine is slow to initialize, the schema was set but the engine binary is missing, or DBus routing inside xvfb is delayed.

Common situations: Slow/loaded CI machine where engine activation exceeds 15s; ibus-hangul schema present but binary absent; a competing input source holding the active engine slot; DBus latency under xvfb-run.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Failed to configure IBus Hangul ${key}: ${result.stderr.trim
• ibus-daemon exited early with code ${ibusProcess.exitCode}
• ibus-daemon did not return a PID
• Owned IBus processes survived cleanup: ${evidence.ibusGroupA
• ${name} did not emit readiness within ${startupTimeoutMs}ms:

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/b3d741a1d690418b. Report an issue: GitHub.