fix(diagnostics): handle WouldBlock errors when writing to stdout

[wagenet]

Summary

• Fix panic when oxlint stdout pipe buffer fills up
• Add retry logic for WouldBlock errors with 1ms backoff
• Handle Interrupted and BrokenPipe gracefully

When oxlint is spawned as a child process (e.g., via Node.js execa/child_process), stdout is connected to a pipe. If the parent process doesn't consume output fast enough, the pipe buffer fills (8KB on macOS, 64KB on Linux) and writes return WouldBlock (EAGAIN, error code 35 on macOS). Previously this caused a panic:

Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }

This PR replaces write_all with write_all_retry that properly handles transient I/O errors by retrying.

Test plan

• Added unit tests for write_all_retry and flush_retry
• Tests cover: success, WouldBlock retry, BrokenPipe, other errors, partial writes, empty buffer

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes a panic in oxlint when writing to stdout pipes by implementing proper retry logic for transient I/O errors. When oxlint is used as a child process and the parent doesn't consume output fast enough, the pipe buffer fills and write operations return WouldBlock errors, which previously caused panics.

Key changes:

• Replaced check_for_writer_error with write_all_retry and flush_retry functions that handle WouldBlock, Interrupted, and BrokenPipe errors
• Added 1ms sleep backoff for WouldBlock retries to prevent busy-waiting
• Implemented comprehensive unit tests with mock writers simulating various error conditions

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The return value of write_all_retry (which indicates success or broken pipe via Ok(true) vs Ok(false)) is being ignored by calling unwrap() directly. Consider handling the Ok(false) case explicitly to distinguish between successful writes and broken pipe scenarios, or document why ignoring this distinction is acceptable.

[Copilot]

The return value of write_all_retry (which indicates success or broken pipe via Ok(true) vs Ok(false)) is being ignored by calling unwrap() directly. Consider handling the Ok(false) case explicitly to distinguish between successful writes and broken pipe scenarios, or document why ignoring this distinction is acceptable.

[Copilot]

The return value of write_all_retry (which indicates success or broken pipe via Ok(true) vs Ok(false)) is being ignored by calling unwrap() directly. Consider handling the Ok(false) case explicitly to distinguish between successful writes and broken pipe scenarios, or document why ignoring this distinction is acceptable.

[Copilot]

The return value of flush_retry (which indicates success or broken pipe via Ok(true) vs Ok(false)) is being ignored by calling unwrap() directly. Consider handling the Ok(false) case explicitly to distinguish between successful flush and broken pipe scenarios, or document why ignoring this distinction is acceptable.

Suggested change

	Self::flush_retry(writer).unwrap();
	match Self::flush_retry(writer) {
	Ok(true) => {
	// Flushed successfully; nothing else to do.
	}
	Ok(false) => {
	// Broken pipe / consumer gone: stop writing and return the result.
	return result;
	}
	Err(e) => {
	// Preserve previous behavior of panicking on unexpected I/O errors.
	panic!("failed to flush diagnostics output: {e}");
	}
	}

[codspeed-hq]

CodSpeed Performance Report

Merging #17238 will not alter performance

_{Comparing wagenet:handle-blocked-stdout (e5a2985) with main (e08fdf1)¹}

Summary

✅ 42 untouched
⏩ 3 skipped²

Footnotes

1. No successful run was found on main (c14afd3) during the generation of this report, so e08fdf1 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

2. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩