fix(retrieval): resolve the reranker provider before acquiring its runtime

[citron07r]

Problem

LocalReranker::new_with_ep acquired, initialized and dependency-checked the ONNX Runtime library for the requested execution provider, and only build_session resolved. Under CoreML those differ: reranker_execution_provider maps CoreMl to Cpu unconditionally, because no prebuilt reranker export runs on the CoreML GPU (the fix from #33/#41).

Three consequences, in increasing order of seriousness:

1. Every Apple Silicon run downloaded and validated ~/.vera/lib/coreml/libonnxruntime.dylib for a session that is always built on CPU.
2. ensure_provider_dependencies ran the CoreML shared-library check that production reranking never needs, since it early-returns for Cpu.
3. ensure_ort_runtime is a process-wide OnceLock, so only the first path passed to it in a process is actually loaded. The embedding provider resolves its own library first, so the reranker could validate the CoreML dylib and then build against whichever library the embedding path had already loaded.

Point 3 is why this is more than wasted bandwidth: the check and the load could disagree, so a green check was not evidence the session would get that library.

Change

All three entry points (new_with_ep, probe_session, probe_inference) resolve first, which is the shape LocalEmbeddingProvider::new_with_ep_and_mem_limit already uses via resolve_provider_and_config.

build_session no longer re-resolves, since all three of its callers now do. Keeping it would put the same contract in two places that could drift, which is the defect this PR is fixing one layer up.

Verification

The behavioural change, measured by resolving each provider to its library path:

requested=coreml -> /Users/citron07r/.vera/lib/coreml/libonnxruntime.dylib
resolved =cpu    -> /Users/citron07r/.vera/lib/libonnxruntime.dylib

So under CoreML the reranker now acquires the library it actually builds against, rather than a second copy it never loads.

End to end on this Apple Silicon machine with the CoreML backend, reranking still works and nothing regressed:

ok  probe-reranker-session  reranker session created
ok  probe-tiny-inference    embedding and reranker returned finite outputs

vera search returns the expected match, which exercises the rerank path.

Test

Asset-free on purpose. The existing test_local_reranker early-returns when ONNX Runtime is not on the default lookup path and passes without asserting anything, so a test routed through session creation would prove nothing on a machine without ORT.

The new test pins the two properties the change depends on: that resolution is idempotent, which is what makes dropping the second resolve in build_session safe, and that CoreML maps to CPU while CUDA and CPU are untouched.

786 vera-core tests, 97 vera-cli, cargo fmt --check clean, clippy unchanged at the 5 pre-existing warnings.

Note

Found while fixing the doctor-side half in #72, where vera doctor --probe preflighted the requested provider but probed the effective one. That PR is scoped to doctor.rs; this is the vera-core half, kept separate because it changes what gets downloaded and which library is initialized at runtime.

Fixes #89

---

Summary by cubic

Resolves the reranker’s execution provider before acquiring ONNX Runtime and reuses an already-initialized runtime under CoreML. This removes unnecessary downloads/checks and prevents library mismatches caused by the process-wide runtime lock.

• Entry points resolve first: new_with_ep, probe_session, probe_inference. build_session trusts the caller and does not re-resolve.
• CoreML-specific guard: if ORT is already initialized, the reranker skips acquiring a CPU runtime; otherwise it acquires for the effective provider and runs dependency checks only when a library is acquired.
• Adds ort_runtime_initialized and asset-free tests that assert idempotent resolution, CoreML→CPU mapping, and CoreML runtime reuse without extra CPU acquisition.
• Behavior on Apple Silicon: acquires ~/.vera/lib/libonnxruntime.dylib (CPU) instead of the CoreML dylib, or skips acquisition when the runtime is pre-initialized. No API or migration changes.

^{Written for commit 96892b8. Summary will update on new commits.}

Summary by CodeRabbit

• Bug Fixes
  • Improved execution provider handling during reranker setup and runtime initialization.
  • Added reliable fallback from CoreML to CPU execution when needed.
  • Prevented duplicate provider resolution and unnecessary runtime acquisition.
  • Improved reuse of initialized runtime components for more efficient reranker startup.
  • Added checks to ensure runtime-dependent operations proceed only after successful initialization.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 1b907bf9-1346-48f3-898b-738c4ab45594

📥 Commits

Reviewing files that changed from the base of the PR and between 4359bcc and 96892b8.

📒 Files selected for processing (2)

• crates/vera-core/src/local_models/ort.rs
• crates/vera-core/src/retrieval/local_reranker.rs

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The reranker resolves execution providers before ONNX Runtime setup in construction and probe paths. Session construction consumes the resolved provider. CoreML can reuse an initialized runtime, and tests cover provider resolution and runtime acquisition.

Changes

Reranker provider resolution

Layer / File(s)	Summary
Runtime state and acquisition crates/vera-core/src/local_models/ort.rs, crates/vera-core/src/retrieval/local_reranker.rs	The code reports successful ONNX Runtime initialization and skips redundant CPU runtime acquisition when CoreML has already initialized the runtime.
Provider resolution and session validation crates/vera-core/src/retrieval/local_reranker.rs	Construction and probe entry points resolve the execution provider before runtime setup. build_session accepts the resolved provider without resolving it again. Tests cover idempotence, CoreML-to-CPU mapping, and provider-specific acquisition.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Merge Risk: ⚪ Minimal · up to 96892

This localized change makes reranking acquire the runtime for its effective execution provider and reports successful verification; no actionable merge-blocking risk remains beyond normal checks and review.

Possibly related PRs

• VeraTools/Vera#33: Directly relates to CoreML-to-CPU reranker provider handling.

Suggested reviewers: lemon07r, flier268

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes resolve the provider before runtime acquisition, initialization, dependency checks, and session construction in the required reranker entry points [#89].
Out of Scope Changes check	✅ Passed	The changes remain within scope and support provider resolution, runtime initialization checks, and the related tests.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary change: resolving the reranker provider before acquiring its runtime.

---

_{Comment @coderabbitai help to get the list of available commands.}

[cubic-dev-ai]

All reported issues were addressed

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>