Skip to content

fix: discard Close errors explicitly so golangci-lint passes - #7

Merged
baiirun merged 1 commit into
mainfrom
fix/errcheck-rows-close
Sep 23, 2026
Merged

baiirun merged 1 commit into
mainfrom
fix/errcheck-rows-close

Conversation

@baiirun

@baiirun baiirun commented Sep 23, 2026

Copy link
Copy Markdown
Owner

The lint CI job has failed on every run since Feb 10, including on main, so every open PR shows a red check regardless of what it changes. The Node 20 deprecation notices in the logs are warnings only — build, test, and format use the same actions and pass.

The actual failures are golangci-lint's errcheck: 15 calls to rows.Close() / conceptRows.Close() in internal/db/labels.go and internal/db/learnings.go whose error return was silently dropped. CI only listed 6 because golangci-lint collapses repeats of the same message by default (max-same-issues: 3); running with --max-same-issues 0 shows all 15.

What changed

The rest of internal/db (deps.go, queries.go, items.go) already uses defer func() { _ = rows.Close() }() to mark the error as deliberately ignored. These two files missed that convention; this applies it:

  • labels.go, learnings.go — deferred closes get the wrapper; inline closes on early-return paths become _ = conceptRows.Close()
  • learnings_test.go — clearing errcheck surfaced a staticcheck SA5011 (possible nil dereference) in TestGetCurrentTaskID. It's a false positive, since t.Fatal stops the test before the dereference, but it's restructured as else if rather than suppressed, so it's correct without the analyzer needing to know t.Fatal doesn't return.

No behavior change: the Close errors were already being ignored; this makes that explicit.

Validation: golangci-lint run --max-same-issues 0 --max-issues-per-linter 0 with v2.7.2 (the version CI pins) reports 0 issues; tests pass.

Once this merges, #6 should go green after a re-run or rebase.

🤖 Generated with Claude Code

The lint job has failed on every CI run since Feb 10, including on main.
golangci-lint's errcheck flagged 15 calls to rows.Close() and
conceptRows.Close() in internal/db/labels.go and internal/db/learnings.go
whose error return was silently dropped. CI only showed 6 of them because
golangci-lint collapses repeats of the same message by default.

The rest of internal/db already uses `defer func() { _ = rows.Close() }()`
to mark the error as deliberately ignored; these two files predate or
missed that convention. This applies the same pattern: deferred closes
get the wrapper, and inline closes on early-return paths become
`_ = conceptRows.Close()`.

Clearing errcheck surfaced one staticcheck SA5011 in
TestGetCurrentTaskID: a false positive, since t.Fatal stops the test
before the dereference. It is restructured as `else if` rather than
suppressed, which is correct without the analyzer needing to know
t.Fatal does not return.

No behavior change: Close errors were already ignored; this only makes
that explicit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@baiirun
baiirun merged commit 1479929 into main Sep 23, 2026
4 checks passed
@baiirun
baiirun deleted the fix/errcheck-rows-close branch September 23, 2026 03:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant