Share compute stuck at "Starting…" — layer download hangs at ~70 MB

[smashhadams]

Environment: Buzz desktop v0.5.3 (aarch64), macOS 26.5.2, Apple M3, 6 GB AI memory

Steps to reproduce:

1. Settings -> Compute
2. 2. Model: unsloth/gemma-4-E4B-it-GGUF:Q4_K_M (the recommended one)
3. 3. Toggle "Share this machine"
      Expected: Model downloads, sharing starts.

Actual: UI stays on "Starting…" indefinitely, then times out; the toggle becomes unresponsive until the app is restarted. After restart the status shows "Checking status…".

Diagnosis from local cache inspection: The base GGUF (4.98 GB) downloads successfully into ~/Library/Caches/huggingface/hub/models--unsloth--gemma-4-E4B-it-GGUF. The subsequent meshllm layers download (models--meshllm--gemma-4-E4B-it-Q4_K_M-layers) stalls at exactly 70.8 MB and never resumes — confirmed across multiple attempts and app restarts, including a fresh reinstall to /Applications. Network is not the issue: a 5 GB browser download from Hugging Face completed in minutes on the same connection while Buzz was stuck.

Also noted: entering a local file path (plain or file://) in the Model field is rejected with "Expected an exact model ref", even though the UI text says a local file is accepted — so there is no user-side workaround.

[iroiro147]

Diagnostic findings for the next implementer

I traced this into the desktop mesh-llm stack. The base GGUF lands fine but the meshllm layers download stalls at exactly 70.8 MB. Relevant structure:

Where the download happens. desktop/src-tauri/src/mesh_llm/mod.rs → ensure_model_downloaded (:329) calls the vendored pinned SDK mesh_llm_host_runtime::models::download_model_ref_with_progress_details(model, true). The byte-progress sink and HTTP chunk loop live inside that pinned crate, not in buzz code — so a fix that changes resume/chunk behavior has to land in the SDK pin or be layered via the transport policy, not a local mod.rs edit.

Two separate defects are conflated in this issue:

1. Download stall at ~70.8 MB. A hard boundary at a round byte offset across restarts (including fresh installs) strongly suggests the layer download's chunk/resume reader wedges at a fixed offset — likely a partial-read that is neither retried nor surfaced as an error, leaving the byte-progress sink permanently short. The vendored SDK's resume reader is the place to look (search for the range/chunk read loop and whether a short read that returns 0 is treated as EOF-complete vs. error). Worth confirming with a packet/log capture whether the HTTP connection is being closed cleanly at that offset (server-side range limit) or the client reader is hanging.

2. Local-file model ref rejected. MeshComputeSettingsCard.tsx accepts a local path (file://) in copy but the validator enforces an exact HF-style model ref (Expected an exact model ref). Either the validator should accept the file scheme the UI advertises, or the UI copy should be corrected. This is the smaller, independent fix and removes the user-side workaround blocker.

Recommended split: land (2) as its own small PR (validation/copy alignment) so users have an interim workaround; treat (1) as an SDK-pin / transport-policy investigation. I did not change the vendored download path in this pass because it's a large, runtime-affecting surface that deserves its own repro + test against the pinned crate.

Happy to take the (2) validation/copy PR.

[iroiro147]

Claimed by AOVPR — sub-issue 2 (validation/copy alignment) ready in PR #4104.

Per my earlier comment: sub-issue 1 (the underlying ~70 MB layer-download stall inside the vendored SDK) is left as its own SDK-side investigation; this PR only addresses the UI/validator mismatch.

• Branch: `iroiro147:claude/issue4049-modelref-validation-20260801` (commit `9f0a856f`)
• What changed: dropped the `local-path` branch from `classifyModelRef` (paths now classify as `unknown`, keeping the Share button disabled with a clear UI-level signal) + corrected the descriptive copy in `MeshComputeSettingsCard.tsx` to stop promising local-file input.
• SDK constraint verified: `parse_exact_model_ref` in pinned mesh-llm `v0.74.0` has only `Catalog` and `HuggingFace` variants — no `LocalPath`. Any path fed into `mesh_start_node` always errors with "Expected an exact model ref".
• Verification: 10/10 classifier unit tests pass; tsc clean; 2/2 playwright e2e mesh-compute smoke tests pass against a fresh build.
• DCO ✓.

Sub-issue 1 still open and unclaimed — I do not have a fix for the vendored SDK download loop.