Bug Description
In pkg/github/repository_resource.go (lines 193-199), defer resp.Body.Close() is registered before the error check on the response. When the underlying HTTP call fails and returns (nil, err), the deferred function panics with a nil pointer dereference.
Affected Code
File:pkg/github/repository_resource.go, lines 193-200
resp, err:=rawClient.GetRawContent(ctx, owner, repo, path, rawOpts)
deferfunc() {
_=resp.Body.Close() // defer registered HERE — captures resp by reference
}()
switch {
caseerr!=nil:
returnnil, fmt.Errorf("failed to get raw content: %w", err) // returns with resp==nilPanic Path
GetRawContent in pkg/raw/raw.go returns (nil, err) when:
newRequest fails (e.g., invalid URL, cancelled context) — line 69client.Do(req) fails (DNS failure, TLS error, network timeout) — per Go stdlib http.Client.Do contract
When this happens:
resp is nil- The
defer was already registered on line 194 - Function returns via the
case err != nil branch - Deferred function runs:
resp.Body.Close() → nil pointer dereference → panic
Expected Behavior
Deferred close should guard against nil:
deferfunc() {
ifresp!=nil&&resp.Body!=nil {
_=resp.Body.Close()
}
}()Or move the defer after the error check (matching the pattern used in other files like repositories.go line ~1307-1312).
Actual Behavior
Server panics if the raw content HTTP call fails at the transport level.
Proposed Solution
Option A (recommended): Add nil guard in the defer
deferfunc() {
ifresp!=nil&&resp.Body!=nil {
_=resp.Body.Close()
}
}()Option B: Move the defer below the error check (same pattern as repositories.go)
resp, err:=rawClient.GetRawContent(ctx, owner, repo, path, rawOpts)
iferr!=nil {
returnnil, fmt.Errorf("failed to get raw content: %w", err)
}
deferfunc() { _=resp.Body.Close() }()| Aspect | Option A | Option B |
|---|
| Safety | Handles partial responses (non-nil resp with error) | Cleaner but skips closing on partial responses |
| Consistency | Matches guarded pattern in other functions | Matches sequential pattern in repositories.go |
Happy to submit a PR for this fix.
Bug Description
In
pkg/github/repository_resource.go(lines 193-199),defer resp.Body.Close()is registered before the error check on the response. When the underlying HTTP call fails and returns(nil, err), the deferred function panics with a nil pointer dereference.Affected Code
File:
pkg/github/repository_resource.go, lines 193-200Panic Path
GetRawContentinpkg/raw/raw.goreturns(nil, err)when:newRequestfails (e.g., invalid URL, cancelled context) — line 69client.Do(req)fails (DNS failure, TLS error, network timeout) — per Go stdlibhttp.Client.DocontractWhen this happens:
respisnildeferwas already registered on line 194case err != nilbranchresp.Body.Close()→ nil pointer dereference → panicExpected Behavior
Deferred close should guard against nil:
Or move the defer after the error check (matching the pattern used in other files like
repositories.goline ~1307-1312).Actual Behavior
Server panics if the raw content HTTP call fails at the transport level.
Proposed Solution
Option A (recommended): Add nil guard in the defer
Option B: Move the defer below the error check (same pattern as
repositories.go)Happy to submit a PR for this fix.