Summary
pkg/linters/blankassigncomma/blankassigncomma.go still has no allow-list or comment-aware exception, so it keeps re-flagging an established codebase idiom that contributors use as a manual workaround for a different, broken linter. This is the third time this exact bug has been filed: 61024 then 62862 then now, each prior issue auto-expiring as closed not_planned without the code changing.
Evidence
checkBlankAssignComma at blankassigncomma.go lines 44-57 flags any assignment where every left hand side identifier is blank, with no allow-list of safe callee types and no check for an adjacent explanatory comment:
if len(assign.Lhs) < 2 {
return
}
for _, lhs := range assign.Lhs {
ident, ok := lhs.(*ast.Ident)
if !ok || ident.Name != "_" {
return
}
}
.golangci.yml line 37 disables errcheck repo wide because its exclude-functions mechanism is broken in golangci-lint v2. The blank-assign-comma double-underscore pattern is the manual substitute contributors adopted for that broken mechanism. pkg/workflow/strings.go lines 172-175 is a direct example, with an explicit comment immediately above it:
h := fnv.New64a()
// hash.Hash.Write never returns an error in practice, but check to satisfy gosec G104
_, _ = io.WriteString(h, strings.ToUpper(name))
_, _ = io.WriteString(h, content)
I re-checked both files directly on 2026-09-30: .golangci.yml still disables errcheck for the same stated reason, and strings.go still has both discard lines with the same explanatory comment above them, unchanged. The linter has no mechanism to recognize this comment or the hash.Hash.Write safe-to-ignore contract, so it re-flags a line the codebase already explicitly documented as intentional.
Impact
blankassigncomma is diagnostic-only today (not yet CI-enforced), so there is no build breakage yet, but every one of the 14+ known production sites found in earlier audits (pkg/console/spinner.go, pkg/workflow/maintenance_cron.go, pkg/workflow/compiler_yaml_main_job.go, pkg/workflow/strings.go, and others) would generate noise the moment it is enforced, undermining adoption.
Recommendation
Before reporting, check for either: (a) a known safe-to-ignore callee signature such as hash.Hash.Write, or (b) a comment on the line immediately preceding the assignment, similar to how nolint directives are already detected positionally in this codebase.
Validation checklist
- Add a testdata case mirroring the hash.Hash.Write pattern with its explanatory comment and confirm it is no longer flagged (or add it to an explicit allow-list).
- Confirm a genuinely suspicious double-blank discard with no adjacent comment is still flagged.
- Re-run make test-unit for pkg/linters/blankassigncomma.
Effort: small to medium, one allow-list or comment-check addition plus testdata.
Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 271.2 AIC · ⌖ 4.26 AIC · ⊞ 5.3K · ◷
Summary
pkg/linters/blankassigncomma/blankassigncomma.go still has no allow-list or comment-aware exception, so it keeps re-flagging an established codebase idiom that contributors use as a manual workaround for a different, broken linter. This is the third time this exact bug has been filed: 61024 then 62862 then now, each prior issue auto-expiring as closed not_planned without the code changing.
Evidence
checkBlankAssignComma at blankassigncomma.go lines 44-57 flags any assignment where every left hand side identifier is blank, with no allow-list of safe callee types and no check for an adjacent explanatory comment:
.golangci.yml line 37 disables errcheck repo wide because its exclude-functions mechanism is broken in golangci-lint v2. The blank-assign-comma double-underscore pattern is the manual substitute contributors adopted for that broken mechanism. pkg/workflow/strings.go lines 172-175 is a direct example, with an explicit comment immediately above it:
I re-checked both files directly on 2026-09-30: .golangci.yml still disables errcheck for the same stated reason, and strings.go still has both discard lines with the same explanatory comment above them, unchanged. The linter has no mechanism to recognize this comment or the hash.Hash.Write safe-to-ignore contract, so it re-flags a line the codebase already explicitly documented as intentional.
Impact
blankassigncomma is diagnostic-only today (not yet CI-enforced), so there is no build breakage yet, but every one of the 14+ known production sites found in earlier audits (pkg/console/spinner.go, pkg/workflow/maintenance_cron.go, pkg/workflow/compiler_yaml_main_job.go, pkg/workflow/strings.go, and others) would generate noise the moment it is enforced, undermining adoption.
Recommendation
Before reporting, check for either: (a) a known safe-to-ignore callee signature such as hash.Hash.Write, or (b) a comment on the line immediately preceding the assignment, similar to how nolint directives are already detected positionally in this codebase.
Validation checklist
Effort: small to medium, one allow-list or comment-check addition plus testdata.