fix(worker): remove POSIX assumptions that broke the Windows worker - #100
Merged
Merged
Conversation
Antigravity ran the WIN-DEV test (Task D) and reported the honest result: no `Compiling direct RPP job` in the log — the worker aborts on `tar -I zstd` and `/tmp/` paths. Confirmed in the code; three separate spots, all of which stop a Windows worker before it can run ANY dispatched job that needs a toolchain: - toolchain_manager.cpp: `tar -I zstd -xf` is GNU tar syntax. Windows 10/11 ship bsdtar (libarchive) as tar.exe, which rejects -I. bsdtar detects zstd from the stream, so plain `-xf` is correct there. Guarded by _WIN32; POSIX unchanged. - worker.cpp: the received toolchain archive was written to a hardcoded "/tmp/suco_tc_recv_...", which does not exist on Windows, so the transfer failed. Now uses std::filesystem::temp_directory_path(), falling back next to the cache dir if that cannot be determined. - config.cpp: the header-cache directory fell back to "/tmp/.cache/suco/headers" whenever HOME was unset — which is the normal case on Windows. Now tries LOCALAPPDATA/USERPROFILE there, then the platform temp dir. Linux behaviour is unchanged in all three (the POSIX branches are byte-for-byte the old code). Compiles clean on MinGW/Windows. This does not by itself make V3-on-a-Windows-worker work — it removes the blockers that stopped the test from getting that far. Task D stays open until the run shows `Compiling direct RPP job` on WIN-DEV. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This was referenced Jul 31, 2026
MicBur
added a commit
that referenced
this pull request
Jul 31, 2026
…r a retry (#101) AG's honest "No, and here's why" answer (no `Compiling direct RPP job`; aborts on `tar -I zstd` and `/tmp/` paths) found three real Windows-worker bugs, all confirmed and fixed in #100. Any Windows worker died at the toolchain step before reaching a V3 job, which is exactly why the log never showed the line. Credits that explicitly — the answer was worth more than a green tick — and asks for a retry from a WIN-DEV worker rebuilt off current main, with the same three acceptable outcomes (yes / no / can't-run). Keeps the earlier reopen rationale as history. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Merged
MicBur
added a commit
that referenced
this pull request
Aug 4, 2026
…sandboxing (#104) Headline: the client no longer runs -E for eligible TUs (#42). It runs the cheap -MM scan, ships raw source + a project-header bundle, and the worker preprocesses. -42% client CPU on Linux, 3.19x wall-clock on a real 101-TU Windows build. On by default after byte-identity was verified on both platforms (240/240 vs native on Linux; Windows PE/COFF cross-compile identical bar path-string normalisation, with the machine code byte-identical). Time-macro, C++20-module and MSVC TUs fall back automatically; SUCO_REMOTE_PREPROCESS=0 restores the classic path and CI pins both. Also in: opt-in worker compile sandboxing with per-job isolation (#43), a VS Code extension, and the fixes that made a Windows worker functional at all (#100), closed a Windows-specific path-escape hole in the bundle guard (#88), corrected the V3 cross-compile compiler resolution (#66) and the PPA version read (#49). Co-authored-by: Claude Opus 4.8 <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
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.
Antigravity ran the WIN-DEV test (Task D) and reported the honest result: no
Compiling direct RPP jobin the log — the worker aborts ontar -I zstdand/tmp/paths. That "No, and here's why" answer is exactly what the test was for. Confirmed in the code; three separate spots, each of which stops a Windows worker before it can run any dispatched job that needs a toolchain:toolchain_manager.cpptar -I zstd -xfis GNU tar syntax; Windows 10/11 ship bsdtar astar.exe, which rejects-I. bsdtar detects zstd from the stream, so plain-xfis correct there.worker.cpp"/tmp/suco_tc_recv_…", which does not exist on Windows → transfer failed. Nowstd::filesystem::temp_directory_path(), falling back next to the cache dir.config.cpp"/tmp/.cache/suco/headers"wheneverHOMEwas unset — the normal case on Windows. Now triesLOCALAPPDATA/USERPROFILE, then the platform temp dir.Linux behaviour is unchanged — every POSIX branch is byte-for-byte the old code, so this is Windows-only repair. Compiles clean on MinGW/Windows and on Linux (node3, 0 errors). CI covers the Linux smoke on both preprocess paths.
This does not by itself make V3-on-a-Windows-worker work — it removes the blockers that stopped the test from getting that far. Task D stays open until a run actually shows
Compiling direct RPP jobon WIN-DEV.🤖 Generated with Claude Code