fix(desktop): stop promising local-file model refs the SDK can't consume - #4104
Open
iroiro147 wants to merge 1 commit into
Open
fix(desktop): stop promising local-file model refs the SDK can't consume#4104iroiro147 wants to merge 1 commit into
iroiro147 wants to merge 1 commit into
Conversation
The Share compute UI advertised "enter a model reference or local file" and `classifyModelRef` had a `local-path` branch. But the pinned mesh-llm SDK at v0.74.0 only knows two `ExactModelRef` variants — `Catalog` and `HuggingFace` — so every local path routed through `mesh_start_node` fails with "Expected an exact model ref" (issue block#4049, sub-issue 2 of 2). Two-part fix: 1. **Copy.** Drop "or local file" from the descriptive text and add "local files are not supported yet" so the form no longer promises a capability we cannot deliver. 2. **Validator.** Remove the `local-path` branch from `classifyModelRef`; local-path inputs (`/`, `./`, `../`, `~`, `.gguf`, `file://`) now classify as `unknown`, which keeps the Share button disabled with a clear UI-level signal instead of running and dumping a cryptic SDK error at the user. Classifier doc comment explains the SDK constraint and points reclassification at the SDK gaining a `LocalPath` variant. Tests updated: classifier unit tests assert `unknown` for all path shapes (plus `file://` and `../` for completeness); Playwright e2e copy assertion matches the new text. Local verification: 10/10 node-test pass; tsc clean; 2/2 playwright mesh-compute smoke pass. Partial fix for block#4049. The other half — the underlying ~70 MB layer-download stall inside the vendored mesh-llm download loop — is a separate, SDK-side investigation and is explicitly left out of scope here. Signed-off-by: Sarthak Singh <sarthak.singh@juspay.in>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partial fix for #4049 (sub-issue 2 of 2).
What
The Share compute UI told users to "enter a model reference or local file", and
classifyModelRefhad alocal-pathbranch that classified filesystem paths as valid. But the pinned mesh-llm SDKv0.74.0only supports twoExactModelRefvariants —CatalogandHuggingFace— so every local path ended inparse_exact_model_refrejecting with "Expected an exact model ref".This was a silent broken promise: the UI said the feature existed; the SDK said it didn't.
Two-part fix
Copy alignment (
MeshComputeSettingsCard.tsx): drop "or local file" from the descriptive text; add "local files are not supported yet" so the form no longer advertises a capability we cannot deliver.Validation alignment (
classifyModelRef.ts): remove thelocal-pathbranch entirely. Local-path inputs (/,./,../,~,*.gguf,file://) now classify asunknown, which keeps the Share button disabled with a clear UI-level signal rather than letting the submit bubble up a cryptic SDK error.The fn-level doc comment explains the vendored-SDK constraint and points reclassification at an upstream SDK change gaining a
LocalPathvariant.Out of scope (per the issue body's own split)
download_model_ref_with_progress_detailsloop. That is an SDK-pin / transport-policy investigation and belongs in its own PR against the vendored mesh-llm crate. Not attempted here.LocalPathvariant inExactModelRefplus wiring throughEmbeddedServeConfig.models— an SDK change first, then a follow-up here.Verification
pnpm exec tsc --noEmit— clean.node --test src/features/mesh-compute/classifyModelRef.test.mjs— 10/10 pass (was 4 fewer, now includesfile://and../shape coverage).pnpm build:e2e— clean.pnpm exec playwright test tests/e2e/mesh-compute.spec.ts— 2/2 pass; smoke test's copy assertion matches the new text.Files
desktop/src/features/mesh-compute/classifyModelRef.ts— removelocal-pathvariant; treat local-path input asunknown.desktop/src/features/mesh-compute/classifyModelRef.test.mjs— update expectations, expand coverage tofile://and../.desktop/src/features/mesh-compute/ui/MeshComputeSettingsCard.tsx— copy.desktop/tests/e2e/mesh-compute.spec.ts— copy assertion.