test(pm): reproduce downloader cache race on linux

[elrrrrrrr]

Temporary PR to run a Linux GitHub Actions reproduction for downloader cache races.\n\nThis adds an ignored downloader stress repro and a PR-triggered workflow that retries it on ubuntu-latest. The target signal is a resolved cache slot whose package.json becomes zero-length after a racing downloader process is killed post-_resolved.

[gemini-code-assist]

Code Review

This pull request adds new integration tests to crates/pm/src/util/downloader.rs to verify downloading to a shared destination across multiple processes and to reproduce a race condition that can leave a zero-length file. The review feedback suggests improving the test helpers by using the standard library's Child::kill method instead of spawning an external kill process, and replacing synchronous, blocking calls (path.exists() and std::fs::read_dir) with their asynchronous counterparts (crate::fs::try_exists and crate::fs::read_dir) to avoid blocking the Tokio executor.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Instead of spawning an external kill process, which is non-portable and less efficient, use the standard library's Child::kill method. Since child.kill() is already used elsewhere in this test file, doing so here also improves consistency.

        let mut children = children;
        for child in &mut children {
            let _ = child.kill();
        }

[gemini-code-assist]

The path.exists() call is synchronous and blocks the Tokio executor thread. Use the asynchronous crate::fs::try_exists re-export instead. To ensure permission or other critical errors fail early and clearly, propagate I/O errors using ? rather than silently ignoring them or using .unwrap().

Suggested change

	async fn wait_for_path(path: &Path, timeout: Duration) {
	let deadline = Instant::now() + timeout;
	while Instant::now() < deadline {
	if path.exists() {
	return;
	}
	sleep(Duration::from_millis(10)).await;
	}
	panic!("timed out waiting for {}", path.display());
	}
	async fn wait_for_path(path: &Path, timeout: Duration) -> std::io::Result<()> {
	let deadline = Instant::now() + timeout;
	while Instant::now() < deadline {
	if crate::fs::try_exists(path).await? {
	return Ok(());
	}
	sleep(Duration::from_millis(10)).await;
	}
	panic!("timed out waiting for {}", path.display());
	}

References

1. Propagate I/O errors (e.g., from try_exists) using ? rather than silently ignoring them with unwrap_or(false), to ensure permission or other critical errors fail early and clearly.

[gemini-code-assist]

The std::fs::read_dir call is synchronous and blocks the Tokio executor thread. Use the asynchronous crate::fs::read_dir re-export instead to keep the helper fully non-blocking.

    async fn wait_for_ready_files(path: &Path, count: usize, timeout: Duration) {
        let deadline = Instant::now() + timeout;
        while Instant::now() < deadline {
            let mut ready_count = 0;
            if let Ok(mut entries) = crate::fs::read_dir(path).await {
                while let Ok(Some(_)) = entries.next_entry().await {
                    ready_count += 1;
                }
            }
            if ready_count >= count {
                return;
            }
            sleep(Duration::from_millis(10)).await;
        }
        panic!(
            "timed out waiting for {count} ready files in {}",
            path.display()
        );
    }