FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

fix: use synchronous pipes for Windows export workers by richiemcilroy · Pull Request #2395 · CapSoftware/Cap · GitHub

Repository navigation

fix: use synchronous pipes for Windows export workers - #2395

Open
richiemcilroy wants to merge 2 commits into
mainfrom
building/windows-export-pipes-a5f224a5
Open

richiemcilroy wants to merge 2 commits into
mainfrom
building/windows-export-pipes-a5f224a5

Conversation

richiemcilroy commented Sep 30, 2026 •
edited by greptile-apps Bot
Loading

Copy link
Copy Markdown
Member

Windows exports read progress and logs from a separate worker. The existing Windows pipes expose asynchronous handles to a synchronous reader, which can cause Rust to terminate the desktop process when a read has not completed.

Use synchronous pipes for export-worker output on Windows and close the parent’s writer handles immediately after spawn so worker exit produces EOF. Other platforms retain their existing pipe behavior. The export protocol and recording format are unchanged.

Verification

  • Native Windows regression tests passed in CI for this commit. Coverage includes handle mode, concurrent output beyond pipe capacity, repeated workers, worker failure, pending-read cancellation, EOF, and spawn failure.
  • The same helper also passed standalone native Windows testing with Rust 1.88 and Tokio 1.47.1, including ten repeated suite runs. The final suite passed after strengthening the pending-read assertion.
  • Local macOS tests, scoped Clippy with warnings denied, formatting, and a full desktop compile passed. The compile excluded unbuilt packaging resources.
  • Windows workspace Clippy failed on a pre-existing dead_code error in crates/utils/src/export_resources.rs (MemoryPressure::Normal and MemoryPressure::Warning). This file is unchanged from the PR base. Desktop build checks are still running.

Verified commit: 9e1e6b34eb95300c1d5e615168264f87dba73d1f.

Demo and remaining validation

This internal process-I/O change has no distinct visual state. Native handle-mode and subprocess assertions provide direct evidence of the changed behavior; a screen recording would not establish whether the handles are synchronous.

Not yet verified by hand: a full export with the rebuilt Windows application. The original crash has not been reproduced, and the exact caller stack is unavailable. Physical GPU behavior and release packaging/signing remain unverified. No database or schema change is required.

Confidence Score: 5/5

The PR appears safe to merge based on the reviewed changes; the full rebuilt-Windows-application export remains the author's stated validation gate.

Summary

The PR routes export-worker spawning through a shared helper that supplies synchronous stdout and stderr pipes on Windows and retains piped output on other platforms.

  • The helper releases parent writer handles after spawn so worker exit can produce EOF.
  • Regression tests cover output volume, failure, cancellation, spawn errors, and Windows handle mode.

Reviews (3) · Last reviewed commit: "Merge branch 'main' into building/window..."

Copy link
Copy Markdown
Member Author

hey @greptileai, please re-review the PR

Copy link
Copy Markdown
Member Author

hey @greptileai, please re-review the PR

This branch was successfully deployed

1 active deployment
Preview — 07d97fe6 Deployed Oct 5, 2026 by vercel[bot]
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant


Back | FazBrowse Home | New Git URL