[sergo] Sergo Report: STABLE-82-reconcile-plus-resourcetracker-indirection - 2026-10-18

[github-actions[bot]]

Executive summary

Run R100 against github/gh-aw. The custom-linter registry (pkg/linters/registry.go) is STABLE at 82 analyzers, unchanged since R97/R99, so this run did not audit a brand-new linter. Instead it closed out a clean reconcile pass (7 open sergo issues, zero reverse-phantoms) and extended an established bug class into the shared resourcetracker framework behind three CI-enforced linters, producing one new, well-evidenced issue.

Tool and strategy status

Serena stayed STABLE at 24 tools (serena --help reconfirmed, exact 24-name list match, activate_project succeeded against go/typescript/bash language servers with no approval prompt). No tool-surface changes to report.

Strategy split (50/50):

• Cached reuse: re-ran the standing reconcile routine (gh api labels=sergo&state=open) and spot-verified the two oldest open issues by reading the current code directly rather than trusting the open label.
• New exploration: followed up on the prior runs own suggested next step - whether the channel_usage_indirection_blind pattern (first seen in goroutineresourceleak.checkChannelLeak, issue goroutineresourceleak: checkChannelLeak misses usage via function-call indirection (channel_usage_indirection_blind) #69613) shows up anywhere else in the linter suite.

Reconcile findings

All 7 previously open sergo issues were reconfirmed present via a fresh gh api query, matching the prior runs prediction exactly: #68309, #68590, #68591, #68944, #68945, #69223, #69613. Two were spot-verified against current source:

• contextcancelnotdeferred still enforced on native CI only - wasm LINTER_FLAGS omission unfixed (issue 65753 auto-expired, 3rd oc #68309 (contextcancelnotdeferred native-only CI enforcement): confirmed via cgo.yml - the analyzer still appears in exactly one of the two LINTER_FLAGS strings (native), still absent from the wasm job.
• resourcetracker Acquisitions callbacks skip ParenExpr unwrap (acquisition-side mirror of #68310) #68590 (resourcetracker Acquisitions callbacks skip ParenExpr unwrap): confirmed via manualmutexunlock.go - mutexLockAcquisitions still does a bare exprStmt.X.(*ast.CallExpr) assertion with no unwrap call.

Zero reverse-phantoms this run - every tracked issue is still accurate against the live code.

New finding this run

resourcetracker CleanupKey misses cleanup via function-call indirection (filed as a new issue, labeled sergo)

The shared pkg/linters/internal/resourcetracker package backs three CI-enforced linters: manualmutexunlock, fileclosenotdeferred, and contextcancelnotdeferred. Its CleanupKey matching only recognizes a cleanup call written directly as a statement-level call - mu.Unlock(), f.Close(), cancel(). All three per-linter CleanupKey implementations (unlockCallKey, closeCallKey, cancelCallKey) require the call to be a direct SelectorExpr-method or bare-Ident call at the exact statement position.

None of them recognize a resource handed to a helper function that performs the real Unlock/Close/cancel call internally - a common decomposition idiom (a shared teardown helper releasing several resources at once, for example). Since resourcetracker only marks a resource as manually-cleaned-up when CleanupKey matches, this case leaves the tracked state permanently unresolved (no manual flag, no defer flag), and the report condition requires the manual flag to be set first - so no diagnostic ever fires. This is a false negative: the resource genuinely never gets deferred, which is exactly the bug class these three linters exist to catch, but the gap is invisible to all of them simultaneously.

This extends the channel_usage_indirection_blind class identified in #69613 (goroutineresourceleak.checkChannelLeak, a single latent linter with a false-positive instance) to the opposite failure mode - a false negative spanning three CI-enforced linters that share one framework.

Task generated

1. Decide and implement a fix for the resourcetracker CleanupKey indirection gap: either add an escape-analysis heuristic (flag a resource that reaches end-of-function with no recognized cleanup and whose variable appears as a bare call argument after acquisition), or explicitly document the current behavior as a known scope boundary (matching the existing non-descent-into-FuncLit design choice). Add a testdata case per linter (acquire, then hand off to a helper that cleans up internally, no local defer) either way.

Metrics this run

• Findings: 1 new bug class instance (plus a clean 7-issue reconcile with zero reverse-phantoms)
• Tasks generated: 1
• Issues created: 1 (searched existing sergo-labeled issues first, state=all, zero duplicates found)
• Success score: 7/10 (single high-confidence, well-evidenced finding; chose depth over padding rather than forcing weaker findings to fill a quota)

Historical context

This is run 100 of an ongoing series tracked in repo memory (branch memory/sergo). Running totals: 585 cumulative findings, 171 cumulative tasks, average success score 8.68 across all runs. The registry has grown from roughly 41 analyzers around run 44 to 82 today; this run did not see further growth.

Next-run focus

Verify this runs new issue lands and is not auto-closed as a reverse-phantom. Re-tally open sergo issues (expect 8 unless a maintainer bulk-closes). If the registry grows to 83 analyzers, prioritize a fresh first-time audit of the new linter over further exploration of existing veins. If no new linter appears, consider whether any linter outside resourcetracker and goroutineresourceleak tracks resource usage via a closed set of direct syntactic call shapes and would show the same indirection blind spot if probed.

References:
§39094895313

Generated by 🤖 Sergo - Serena Go Expert · claude · agent · 152.8 AIC · ⌖ 0.993 AIC · ⊞ 5.3K · ◷

• expires on Oct 18, 2026, 7:58 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-10-19T03:58:19.233Z.

Closed by Workflow