Fix desktop STL download: native Save As instead of dead HTTP route#1
Merged
Conversation
Downloads went through /__cad/download, a dev-only Vite/Node middleware route that isn't served in the packaged app (only the pandaasset:// scheme is registered). The <a download> therefore saved a 404/SPA-HTML response renamed .stl, which slicers reject as "no geometry data" — even though the on-disk STLs are valid. Files already live locally, so a download is just a local-to-local copy. Add a file_save IPC command that resolves the source under the open project (rejecting `..`), shows the native Save As dialog, and copies the bytes — no HTTP round-trip, no loading the file into JS. The desktop download path now calls it; browser/hosted backends keep the HTTP path since the file isn't local there. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
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.
Problem
Downloading an STL from the packaged desktop app produced a file BambuLab Studio rejected with "the file doesn't contain any geometry data" — even though the on-disk STLs are valid (verified: real facets, real geometry).
Root cause: the download went through
/__cad/download, a dev-only Vite/Node middleware route that isn't served in the packaged app (only thepandaasset://scheme is registered in Rust). The<a download>therefore saved a 404/SPA-HTML response renamed.stl, which slicers read as empty geometry. Works inscripts/dev.sh(Vite serves the route), fails only when bundled.Fix
Files already live locally, so a download is just a local-to-local copy. New
file_saveIPC command:resolve_in_project(rejects..traversal).tauri-plugin-dialog, already wired in).fs::copy. Never touches the source; the OS dialog handles overwrite confirmation. Returns the chosen path, ornullon cancel.The desktop download path now calls
file_save; browser/hosted backends keep the HTTP path since the file isn't local there.Verification
cargo test commands::files— 6 pass (incl. 4 new: path-escape rejection, name/ext derivation, missing-file).cargo buildclean; viewer build typechecks; transport + download test files pass directly (npm testrunner is broken by an unrelated Node 24.6 flag removal).Out of scope
The assembly (
product) still emits noproduct.stl— only individual parts do. Separate gap if whole-product printing is expected.🤖 Generated with Claude Code