opencode plugin can spawn AFT before ONNX runtime path is ready, causing dlopen failed and SIGABRT

[Suknna]

Summary

When experimental_semantic_search=true, the OpenCode plugin can spawn the AFT binary before ONNX runtime initialization finishes. In that window, the child process starts without the resolved ONNX dylib directory, semantic index initialization tries to load libonnxruntime.dylib, and the Rust binary aborts with SIGABRT.

This was reproducible on macOS with the OpenCode plugin and explains repeated restart loops with:

• Failed to load ONNX Runtime dylib
• dlopen failed
• Process exited: code=null, signal=SIGABRT
• Max restarts (3) reached

Environment

• Platform: macOS darwin/arm64
• AFT binary: v0.11.1
• OpenCode: 1.4.3
• Config: experimental_search_index=true, experimental_semantic_search=true

Root Cause

In packages/opencode-plugin/src/index.ts, ensureOnnxRuntime() previously ran asynchronously without being awaited. BridgePool could be created first, and the AFT child process could be spawned before _ort_dylib_dir was populated.

That means the child process environment did not reliably include the ONNX dylib path before semantic index initialization started.

Because the Rust release profile uses panic = \"abort\", ONNX loading failure terminates the process instead of surfacing as a recoverable error.

Reproduction

1. Enable experimental_semantic_search=true
2. Start OpenCode with the AFT plugin
3. Trigger an AFT-backed session quickly on a project that causes semantic indexing to initialize early
4. Observe repeated crashes in aft-plugin.log

Observed log sequence:

• ONNX Runtime found at ...
• Spawning binary: .../v0.11.1/aft
• Failed to load ONNX Runtime dylib: ... dlopen failed
• Process exited: code=null, signal=SIGABRT
• Auto-restart #1/#2/#3
• Max restarts (3) reached

Evidence

I verified this locally from logs and runtime behavior.

Before the fix, hwmon was a reliable repro case and repeatedly crashed during semantic search startup.

After changing plugin startup order so ONNX initialization is awaited before bridge creation, the same setup successfully reached:

• started
• pre-warmed symbol cache
• built semantic index
• semantic index persisted

Example successful post-fix log sequence:

• Spawning binary: /Users/.../.cache/aft/bin/v0.11.1/aft (cwd: /Users/.../hwmon)
• Binary version: 0.11.1
• pre-warmed symbol cache: 63 files
• built semantic index: 76 files, 799 entries
• semantic index persisted: 799 entries, 1707.0 KB

Proposed Fix

In the OpenCode plugin startup path:

• await ensureOnnxRuntime(storageDir) before constructing BridgePool
• set configOverrides._ort_dylib_dir before any child process spawn
• keep the fast path unchanged when experimental_semantic_search=false

Regression Coverage

I added two focused tests locally:

1. ensureOnnxRuntime must resolve before BridgePool construction
2. when semantic search is disabled, ensureOnnxRuntime must not be called

Why This Matters

This is not just a corrupted local ONNX cache case. The race can happen even when the dylib exists and is loadable on disk, because the child process may start before the plugin has injected the runtime directory into process configuration.

[Suknna]

Adding a bit more precise source-level context here in case it helps narrow the fix quickly.

More precise code path

The race appears to be in the OpenCode plugin startup flow:

• packages/opencode-plugin/src/index.ts
  • ensureOnnxRuntime(storageDir) was previously started asynchronously without being awaited
  • _ort_dylib_dir was only written into configOverrides after that async work completed
• packages/opencode-plugin/src/bridge.ts
  • BridgePool / BinaryBridge could be created first and spawn the child process before _ort_dylib_dir was available
  • the child env is fixed at spawn() time, so if the ONNX path is not ready yet, the process starts without the correct runtime path
• crates/aft/src/commands/configure.rs
  • with experimental_semantic_search=true, semantic index / embedding init happens early
• Cargo.toml
  • release profile uses panic = \"abort\"

So the failure mode is effectively:
child process spawns too early -> ONNX runtime load fails -> Rust aborts -> plugin restart loop.

Local fix that worked

The minimal change that fixed this locally was:

• await ensureOnnxRuntime(storageDir) before constructing BridgePool
• set configOverrides._ort_dylib_dir before any child process can spawn
• keep the fast path unchanged when experimental_semantic_search=false

Regression coverage

I also added two focused local tests:

1. ensureOnnxRuntime must resolve before BridgePool construction
2. when semantic search is disabled, ensureOnnxRuntime must not be called

Runtime verification

After that change, the same previously failing hwmon repro with experimental_semantic_search=true consistently reached:

• Spawning binary
• started
• pre-warmed symbol cache: 63 files
• built semantic index: 76 files, 799 entries
• semantic index persisted: 799 entries, 1707.0 KB

and did not produce new:

• Failed to load ONNX Runtime dylib
• dlopen failed
• signal=SIGABRT

If helpful, I can turn this into a minimal PR containing just the startup-order fix plus the two regression tests.

[ualtinok]

Fixed in v0.11.2. Two layers of protection now prevent this:

1. Plugin startup order — ensureOnnxRuntime() is awaited before BridgePool construction, so ORT_DYLIB_PATH is set before any child process spawns.

2. Rust crash prevention — even if the race somehow occurs:

   • pre_validate_onnx_runtime() catches broken/missing .so via raw dlopen before the ort crate touches it
   • panic = "unwind" in the release profile so catch_unwind works against ort panics (previously panic = "abort" made this impossible)
   • Semantic search now degrades gracefully with a logged error and a doctor hint instead of killing the entire AFT process

The Docker E2E test suite (added in v0.11.2) verifies all three ONNX failure scenarios: no ORT, broken .so, and bad ORT_DYLIB_PATH — all pass without crashes.