Go SDK: fix operator-precedence bug that could crash the worker process#70141
Open
ColtenOuO wants to merge 2 commits into
Open
Go SDK: fix operator-precedence bug that could crash the worker process#70141ColtenOuO wants to merge 2 commits into
ColtenOuO wants to merge 2 commits into
Conversation
heartbeater.Run checked `resp != nil && resp.StatusCode() == 404 || resp.StatusCode() == 409` -- `&&` binds tighter than `||`, so the nil guard only covered the 404 branch. A GeneralHTTPError with a nil Response (e.g. a transport-level failure) hit resp.StatusCode() on a nil pointer in the heartbeater's own goroutine, which has no recover, crashing the whole worker process instead of just failing the task. Add parentheses to group both status checks under the nil guard.
ColtenOuO
requested review from
amoghrajesh,
ashb and
jason810496
as code owners
July 20, 2026 17:36
Andrushika
reviewed
Jul 20, 2026
Andrushika
approved these changes
Jul 20, 2026
Andrushika
left a comment
Andrushika
left a comment
Contributor
There was a problem hiding this comment.
LGTM overall, thanks!
…test Address review feedback: wait on a channel signaled by the mocked Heartbeat's second call instead of a fixed 250ms sleep, so the test isn't tied to wall-clock timing that could be flaky under CI load. A second heartbeat call also positively confirms the heartbeater survived processing the first nil-Response error.
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
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
heartbeater.Runin the Go SDK worker checks whether a heartbeat error indicates the server no longer wants the task running (404/409), so it can cancel the task instead of retrying forever:&&binds tighter than||in Go, so this actually parses as(resp != nil && resp.StatusCode() == 404) || resp.StatusCode() == 409-- the second disjunct callsresp.StatusCode()unconditionally, bypassing the nil check theresp != nil &&clearly intended to guard.resphere is*api.GeneralHTTPError.Response(*resty.Response), which can be nil for transport-level failures that never got as far as an actual HTTP response (e.g. connection reset, TLS failure). When that happens,resp.StatusCode()panics on a nil pointer -- and this happens inside the heartbeater's own goroutine (go heartbeater.Run(heartbeatCtx)inExecuteTaskWorkload), which has norecover()of its own. Go'srecover()only catches panics in the same goroutine's call stack, so this crashes the entire worker process, not just the one task.Confirmed by temporarily reverting the fix and running the new test: it panics with
SIGSEGVat exactly this line, unrecovered, exactly as described above.Changes
resp != nil && (resp.StatusCode() == 404 || resp.StatusCode() == 409).TestTaskHeartbeatNilResponseDoesNotPanic, which returns aGeneralHTTPError{Response: nil}from the mocked heartbeat call andasserts the task completes normally instead of crashing.