fix(desktop): build real sidecars in desktop-release-build (0-byte bundle bug) - #68
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
🧪 Jev PR-Triage (v3)PR #68: fix(desktop): build real sidecars in desktop-release-build (0-byte bundle bug) — verdict: REVIEW
🔍 Reviewer focus
Block reason (if any): |
desktop-release-build depended only on _ensure-sidecar-stubs, which touches 0-byte placeholders to satisfy the Tauri compile-time externalBin check, then ran `pnpm tauri build` directly. It never ran cargo build --release or scripts/bundle-sidecars.sh, so released bundles shipped 0-byte sidecars and every in-app `buzz` call silently no-opped (exit 0, empty output) -- as seen in /Applications/Buzz.app, where all six sidecars were 0 bytes. Extract the build+bundle into a shared _build-sidecars recipe and use it from both desktop-release-build and desktop-demo-build, which carried its own copy. Net -1 line, one definition. Verified: cargo release build + bundle-sidecars.sh produce six non-zero arm64 executables (1.3-21 MB) in desktop/src-tauri/binaries/, each responding to --version with real argument/config handling instead of empty output.
cbb9121 to
1c75d43
Compare
Problem
/Applications/Buzz.app/Contents/MacOS/ships all six sidecars at 0 bytes (onlybuzz-desktopis real). Every in-appbuzzinvocation therefore succeeds with exit 0 and empty output — a silent no-op that is very hard to attribute, since nothing errors.Root cause
desktop-release-builddepended only on_ensure-sidecar-stubs, whichtouches 0-byte placeholders so Tauri's compile-timeexternalBinvalidation passes (needed by the clippy/check/test recipes). It then ranpnpm tauri builddirectly and never rancargo build --releaseorscripts/bundle-sidecars.sh. Tauri happily bundled the stubs.desktop-demo-builddid it correctly — the release path simply never got the same treatment.Fix
Extract the build+bundle into a shared
_build-sidecarsrecipe and call it from both release and demo paths, rather than adding a third copy of the logic.desktop-demo-buildhad its own inline copy; the justfile already warns that duplicated sidecar logic drifts apart, so this consolidates instead of duplicating. Net -1 line, one definition._ensure-sidecar-stubsis intentionally left cheap and unchanged — the stubs exist only for the compile-time check used by non-bundling recipes.Verification
Behaviour (the real gate for this change):
Finished release profile in 3m 24s→Sidecars bundled for aarch64-apple-darwin.desktop/src-tauri/binaries/went from six 0-byte files to six non-zero arm64 Mach-O executables:Each was then executed to confirm it is functional, not merely non-empty — all six produce real argument parsing / config validation / MCP handshake output (
file -b→ arm64 for each), versus the stubs' empty exit 0.Recipe semantics:
just --evaluateparses clean;just --dry-run desktop-release-buildshows the dependency order_ensure-sidecar-stubs→_build-sidecars(cargo build → bundle-sidecars.sh) →pnpm install→pnpm tauri build;just --dry-run desktop-demo-build acmeresolves_build-sidecarsvia{{just_executable()}}(absolute path, so it does not depend onjustbeing onPATHinside the recipe).JS gate:
pnpm run checkfromdesktop/→ RC=0 (4 warnings, all pre-existing CSS/lint items untouched by this change). Noting for reviewers that this gate covers desktop JS only and cannot validate justfile semantics — hence the build-level verification above.Scope
Build tooling only; no runtime code. Follows Path B (branch + PR) rather than direct-to-main because build/CI config is a sensitive path under AGENTS.md.