On main at f30f550, internal/tools/format_on_write.go:26 pins formatOnWriteTimeout = 10 * time.Second and applies it at line 85 around one formatter run. When the formatter does not finish in that window the file is written unformatted.
This is the same shape as the test flake fixed in #1018, one layer down: a single fixed window granted to a subprocess to start and produce output, with no distinction between a formatter that is wedged and one that is merely slow to start. The sweep for #1018 measured spawn-to-first-output at 720ms to 1.44s on a developer box with every core busy, and the Windows CI runner is slower, scans a freshly linked binary on first execution, and runs other packages alongside. TestFormatOnWriteFormatsAndKeepsTrackerConsistent asserts the file came back gofmt-formatted, so a slow gofmt fails it, and the same thing in production silently leaves a file unformatted with nothing telling the user.
Filed rather than fixed because the window is owned by the product, not a test, so the decision is different: the timeout exists to stop a wedged formatter from blocking a write forever, and that is right. Options worth weighing rather than just raising the number: report the timeout on the result so the user knows the file was not formatted; bound the wait for first output separately from the wait for completion, so a formatter that has started keeps its budget; or measure the formatter's own startup once per session and budget from that.
The recurring Windows smoke flakes in this repo have had the same root cause before, a production timeout racing process startup, so this is worth treating as a class rather than a constant.
On
mainat f30f550,internal/tools/format_on_write.go:26pinsformatOnWriteTimeout = 10 * time.Secondand applies it at line 85 around one formatter run. When the formatter does not finish in that window the file is written unformatted.This is the same shape as the test flake fixed in #1018, one layer down: a single fixed window granted to a subprocess to start and produce output, with no distinction between a formatter that is wedged and one that is merely slow to start. The sweep for #1018 measured spawn-to-first-output at 720ms to 1.44s on a developer box with every core busy, and the Windows CI runner is slower, scans a freshly linked binary on first execution, and runs other packages alongside.
TestFormatOnWriteFormatsAndKeepsTrackerConsistentasserts the file came back gofmt-formatted, so a slow gofmt fails it, and the same thing in production silently leaves a file unformatted with nothing telling the user.Filed rather than fixed because the window is owned by the product, not a test, so the decision is different: the timeout exists to stop a wedged formatter from blocking a write forever, and that is right. Options worth weighing rather than just raising the number: report the timeout on the result so the user knows the file was not formatted; bound the wait for first output separately from the wait for completion, so a formatter that has started keeps its budget; or measure the formatter's own startup once per session and budget from that.
The recurring Windows smoke flakes in this repo have had the same root cause before, a production timeout racing process startup, so this is worth treating as a class rather than a constant.