[sergo] Sergo Report: DELTA-73to74-newlinter-audit(closeerrorunchecked)+reconcile-2-reverse-phantoms - 2026-09-30 #64400
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Sergo - Serena Go Expert. A newer discussion is available at Discussion #64682. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Executive Summary
Run 82 found the registry grew for the first time since R74 (73 -> 74 analyzers) with the addition of closeerrorunchecked, a linter that flags discarded Close() error return values. Its first-ever audit surfaced a fresh instance of the most recurring bug class in this repository, paren_unwrap_gap, on the very first day the linter existed. Reconciliation also caught two more reverse-phantom closures (issues auto-expired as not_planned while the underlying bug remained 100 percent present in code), continuing a long-running pattern where the issue tracker in this repository auto-expires stale-looking issues faster than they get fixed.
Strategy split this run: roughly 60% cached / 40% new-explore (leaning cached because a new linter appeared, which is itself the highest-value new-explore target by convention, so the new component was folded into the mandatory new-linter audit rather than a separate cold-start probe).
Tool Updates
Strategy Split Details
Cached component (reconcile, ~60%): Re-verified all 15 issues open at the start of this run via gh api issues?labels=sergo&state=open. Two had auto-expired to closed/not_planned since the last run:
Both were refiled with full evidence citations rather than treated as fixed.
New-explore component (~40%): With the registry growing for the first time in 8 runs, budget went to a full first-read audit of closeerrorunchecked rather than a cold probe of already-audited linters. The audit confirmed the linter is well-designed on type-identity (it correctly distinguishes the builtin error interface from a package-local type literally named error in its own test fixtures, avoiding the syntactic_stdlib_match class entirely) but reproduces the paren_unwrap_gap class that has now been found independently in roughly a dozen other linters across the history of this codebase.
Findings
Generated Tasks / Issues Created
Three issues filed this run (max allowed: 3):
Dedup was confirmed via gh api search/issues before filing all three (zero prior bug-report coverage beyond the closeerrorunchecked creation PR itself, and the two reconciled issues are direct refiles of their own prior filings).
Metrics
Historical Context
This is run 82 of an ongoing daily series (started ~R42 in the continuous history of this memory). Running totals after this run: 82 total runs, ~508 cumulative findings, ~146 cumulative tasks/issues, average success score ~8.75/10. The registry has grown from 42 analyzers (R58) to 74 today, with closeerrorunchecked as the 14th analyzer added since the registry migrated to pkg/linters/registry.go at R61. The paren_unwrap_gap class alone has now been found in at least 13 distinct locations (nilctxpassed, errstringmatch, sprintfbool, tolowerequalfold, timenowsub, httpstatuscode, seenmapbool, the shared astutil string-literal helpers, and now closeerrorunchecked), making it the single most recurring bug class this workflow has ever catalogued - strong evidence that a shared lint-authoring template or code-review checklist item (call astutil.UnwrapParenExpr before any bare AST type assertion on a call/literal/ident) would prevent an entire category of future first-audit findings.
Recommendations
Next-Run Focus (R83)
All reactions