[sergo] Sergo Report: Adjacency-Probe Sweep + Channel Indirection Audit - 2026-10-17

[github-actions[bot]]

Executive Summary

Run R99 (workflow run ID 39000079926). Serena stable at 24 tools; linter registry stable at 82 analyzers (no new linter since R97's deferrerrorunchecked). Reconcile found 6 open sergo-labeled issues instead of the 5 predicted by memory, because an untracked run on 2026-10-16 (retroactively labeled R98) filed issue #69223 but never updated repo-memory -- flagged as a process gotcha below. Spot-checked 2 of the oldest opens via direct code read; both still accurate, zero reverse-phantoms. New-explore exhausted R97's suggested probe list (deferinloop, wgdonenotdeferred, timeafterleak, plus bufioscannererunchecked) for the adjacent_defer_assumption class -- all four clean -- then pivoted to a first-ever audit of goroutineresourceleak's third check, checkChannelLeak, which turned up a new, distinct bug. 1 new issue filed.

Tool & Registry Status

• Serena: 24 tools, STABLE (cached from 3+ consecutive confirmations, not re-tested live this run)
• Linter registry: 82 analyzers, STABLE (grep -c 'Analyzer,$' registry.go=82, matches doc.go header, no drift)

Strategy Split (50/50)

Cached reuse (reconcile): Re-verified the 2 oldest opens via direct code read instead of trusting labels:

• contextcancelnotdeferred still enforced on native CI only - wasm LINTER_FLAGS omission unfixed (issue 65753 auto-expired, 3rd oc #68309 (contextcancelnotdeferred wasm-omission, lineage contextcancelnotdeferred is enforced on native CI but absent from wasm LINTER_FLAGS - the registry-drift guard cannot detect it #55932->65753->68309): cgo.yml grep for the linter name still returns exactly 1 hit (native only) -- unchanged, still accurate
• resourcetracker Acquisitions callbacks skip ParenExpr unwrap (acquisition-side mirror of #68310) #68590 (resourcetracker Acquisitions-callback paren gap): resourcetracker.go:188 still invokes c.Acquisitions(pass, node) with the raw node, and all three callbacks (manualmutexunlock.mutexLockAcquisitions, fileclosenotdeferred.fileOpenAcquisitions, contextcancelnotdeferred.cancelFuncAcquisitions) still bare-assert *ast.CallExpr with no astutil.UnwrapParenExpr -- unchanged, still accurate

#68591, #68944, #68945, #69223 were not individually re-verified this run (all filed within the last 2 days, low reverse-phantom risk) -- budget was redirected to new-explore instead.

New exploration: Followed R97's own suggested next step exactly: probed deferinloop.go, wgdonenotdeferred.go, and timeafterleak.go for the adjacent_defer_assumption class (a block-scanning cleanup-detector that requires the matching defer to be the literal next statement, false-flagging any intervening bookkeeping statement). All three are structurally immune -- deferinloop and timeafterleak use ancestor-walks (Cursor.Enclosing) with no statement-list scanning at all, and wgdonenotdeferred reports immediately per ExprStmt site rather than accumulating adjacency-dependent state. A bonus check of bufioscannererunchecked.hasScannerErrCheck (a known block_scope_state_reset instance from R66) confirmed it is independently clean for this specific class too -- it performs a genuine forward scan of the rest of the block rather than a single-next-statement check.

With that list exhausted, pivoted to a first-ever audit of goroutineresourceleak.checkChannelLeak (prior runs only covered checkCancelLeak/checkMutexLeak). Found that channel-usage recognition is limited to three direct inline syntactic forms (send, close, receive) with zero awareness of a channel being handed to a helper function -- a common and safe decomposition pattern that this check cannot distinguish from an actual leak.

Findings & Generated Task

sg99a1 -- goroutineresourceleak.checkChannelLeak indirection blind spot (new issue filed)

• Problem: createdChannels/markChannelUsage (goroutineresourceleak.go:173-236) only mark a channel as used via a direct SendStmt, a literal close() call, or a unary receive, all within the goroutine's own body
• Impact: a goroutine that creates a channel and passes it to a well-behaved helper function for the actual I/O gets a false-positive leak report, since none of its usage happens through a recognized syntactic form
• Evidence: zero testdata coverage for this shape; no live prod repro found in a quick spot-check (most prod goroutines in this codebase use sync.WaitGroup rather than self-created channels), so this is filed as a latent, reasoned finding
• New pattern class: channel_usage_indirection_blind

Metrics

• Findings this run: 2 (the 4-linter adjacency-clean sweep, and the new channel-indirection bug)
• Tasks/issues created: 1
• Success score: 7/10 (solid negative sweep plus one genuine new bug; did not force weaker padding issues)
• Cumulative: 99 runs, 584 findings, 170 tasks, avg success 8.69

Historical Context

This is the 5th linter-family bug found in the Close/Lock/cancel/channel resource-lifecycle space in the past 6 runs (paren_unwrap_gap and adjacent_defer_assumption on goroutineresourceleak, the acquisition-side mirror on resourcetracker, the slicemakezerolength generalization, and now this channel-indirection gap) -- goroutineresourceleak in particular has now had a distinct bug found in all three of its checks (cancel, mutex, channel).

Process Note (Gotcha)

An untracked run executed 2026-10-16 and filed issue #69223 (a correct, well-formed finding generalizing adjacent_defer_assumption to slicemakezerolength) but never appended to any of the three repo-memory files. This run only discovered the gap because the gh api reconcile step is always run fresh rather than trusting memory's predicted tally. Repo-memory updated this run to record the gap explicitly; future runs should continue treating a fresh reconcile query as authoritative over memory's cached prediction.

Next-Run Focus

• Verify sg99a1 (channel_usage_indirection_blind) landed; re-tally opens (expect 7 unless bulk-closed)
• If registry grows to 83, audit the new linter fresh
• Confirm this run's own memory writes persisted (the prior run's silently did not)
• No further untried candidates identified for adjacent_defer_assumption; channel_usage_indirection_blind vein could extend to other resource-usage scans if a similar fixed-syntactic-form pattern is found elsewhere

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

• expires on Oct 17, 2026, 7:59 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Sergo - Serena Go Expert.

A newer discussion is available at Discussion #69835.