Fix SIGPIPE race in go.mod Go-version parsing - #10
Conversation
curl was piped directly into awk '{... exit}'. Once awk matches the
"go X.Y" line (near the top of go.mod) it exits immediately, closing
the pipe's read end while curl may still be writing the rest of the
response body. That races curl into a SIGPIPE and exit code 23 under
pipefail. Capture curl's output into a variable first, then parse it
with awk, so the download always completes before parsing starts.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Note: because both automatic attempts for v3.14.0 failed (this bug), the formula is still pinned to v3.13.0 / go@1.24. |
Summary
curlexiting 23 ("failed writing received data").curl -fsSL "$GO_MOD_URL" | awk '/^go [0-9]/{print $2; exit}'— thego X.Yline sits near the top ofgo.mod, soawkmatches almost immediately and itsexitcloses the pipe's read end whilecurlmay still be writing the rest of the (now larger, dependency-heavy) response body. That's a SIGPIPE race:curlgets a write error and returns 23, whichset -o pipefailturns into a step failure. This explains why it worked for months and only recently started failing —go.modgrew enough thatcurlnow issues multiple writes, widening the race window.awkover it. This removes the pipe entirely so parsing never races the download.Test plan
v3.14.0/src/go.mod) — correctly resolvesGO_FULL=1.25.9.repository_dispatch(or manualworkflow_dispatch) run after merge.🤖 Generated with Claude Code