workers: resolve the worker binary beside the module when no explicit path is set - #12
Conversation
…n certify Owned-CUDA has no declared or inherited certification path: a measured probe row must exist before serving, and the probe resolves reference fixtures by (family, reference_model). The shipped embed fixtures only cover minilm and gte-modernbert, so a qwen3-0.6b/owned-cuda model dead-ends at reference_fixture_missing with no supported way to certify. Add the missing set: 64 items, the same corpus texts as the shipped fixtures, reference vectors generated on CPU with candle-transformers 0.10.2 f32 (last-token pool + L2), independent of the CUDA kernels under test. Wire it into probe_fixtures() and resolve the qwen3-embedding model-id family/reference names so the fixture matches without an engine build flag, mirroring the minilm/modernbert fallbacks. Verified locally: the fixture scores mean cosine 0.99999771 / worst decile 1.0 against the owned-CUDA lane (thresholds 0.999 / 0.9), and the new registry test pins family/reference/dims for all three sets.
… path is set A worker-engine model refuses to load unless the catalog entry or the engine env var (SYNAPSE_<ENGINE>_WORKER_BIN) supplies a worker path. The release archives already unpack every binary at the archive root, so an installed ck-synapse sits next to ck-synapse-worker-*, yet nothing looks there and every fresh install needs hand-set env or per-model worker_bin entries before a single worker-engine model can load. Add sibling resolution as the last fallback in the resolution chain: spec worker_bin -> engine env var -> ck-synapse-worker-<engine> beside the running module binary (name table in worker_engine_names, so the contract lives next to the HELLO identity constants). When no sibling exists the refusal keeps its shape and now names all three sources. No behavior change when an explicit path or env var is present; the owned-decode lane keeps its own resolution for now.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 3 files
Not reviewed (too large): crates/synapse-module/src/fixtures/probe_corpus_qwen3_embedding_fp32.json (~65,932 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.
Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
Re-trigger cubic
The Windows-only set_extension call made `candidate` needlessly mutable on every other target, and CI runs clippy with -D warnings on linux. Rebind under cfg(windows) instead; no behavior change on either target.
The sibling-resolution table hardcoded "owned-cuda" and "owned-metal-decode" while the same file already exports CUDA_WORKER_ENGINE and DECODE_WORKER_ENGINE with exactly those values. The file's own doc comment says every producer and consumer must use the shared constant so a catalog rename cannot silently break the contract; the literals defeat that for the new fallback. Match on the constants instead. LLAMA_ENGINE covers llama; mlx/ane have no catalog-name constant (the MLX_WORKER_ENGINE/ANE_WORKER_ENGINE constants are HELLO identities, a different string), so those two stay literal.
|
Addressed the cubic P3 in d90c9a7.
Verified: |
A worker-engine model refuses to load unless the catalog entry or the engine env var (
SYNAPSE_<ENGINE>_WORKER_BIN) supplies a worker path:But the release archives already unpack every binary at the archive root, so an installed
ck-synapsesits next tock-synapse-worker-llama/ck-synapse-worker-cuda/ etc. Nothing looks there, so every fresh install needs hand-set env vars (or per-modelworker_binentries) before a single worker-engine model can load — and the CUDA worker isn't even in the release matrix yet, which is exactly the kind of install where operators hit this first.Change
Resolution chain in
load_worker_backend_blockinggains a final fallback:spec.worker_bin(unchanged)ck-synapse-worker-<engine>beside the running module binary (new)The name table lives in
worker_engine_names.rsnext to the HELLO identity constants, so the file-name contract sits with the identity contract.current_exe()+ parent +.exeon Windows, matching the ANE launcher's existing sibling-resolution pattern.When no sibling exists the refusal keeps its shape and now names all three sources:
Notes
owned-metal-decodelane keeps its own resolution path (its refusal is a typedRefused(Unavailable), deliberately distinct) — I left it alone rather than widen this change; can follow up if wanted.cargo test -p synapse-module --lib424 passed / 0 failed (newworker_binary_sibling_names_cover_every_worker_enginetest pins the table),cargo test -p synapse-core --lib52 passed,cargo clippyandcargo fmt --checkclean.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.Summary by cubic
Adds a fallback for worker binary resolution and a Qwen3 embedding probe fixture, so worker-engine models load from a standard install and owned-cuda models can certify.
Worker binary resolution
ck-synapse-worker-<engine>beside the running module binary after checkingworker_binandSYNAPSE_<ENGINE>_WORKER_BIN, with the sibling name table reusing the shared worker-engine constants where available.Probe fixture
reference_fixture_missingdead-end that blocked owned-cuda certification.Written for commit d90c9a7. Summary will update on new commits.