You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Run R91 reconciled cleanly against GitHub (zero reverse-phantom flips, a first in several runs), re-verified all 4 previously filed findings are still accurate via direct code reads, and filed one new issue: a latent nondeterminism bug in the same dormant coverage-gating package that produced last runs finding. Registry and Serena tooling are both stable, so the full exploration budget went into the coverage package and a from-scratch audit of gate-vs-report position alignment across all 15 coverage-gated linters.
Tool and registry updates
Serena: STABLE 24 tools, reconfirmed live via serena --help, exact match to the cached list.
Custom linter registry: STABLE 77 analyzers (grep -c Analyzer,$ pkg/linters/registry.go = 77, no delta since R89/R90; doc.go header still says 77 active analyzers, no drift).
No new linter this run, so no fresh first-audit target was available.
Strategy split (50/50)
Cached reuse (50%): reconcile GitHub state for the 4 open sergo issues first, then re-verify each ones underlying code is still accurate (not just trust the open/closed label) before deciding whether anything needed refiling.
New exploration (50%): follow up on R90s own suggested next step, the coverage.findProfile path-matching logic, but first sanity-check the easier half of that area (whether any of the 15 gated linters pass a mismatched position into ShouldApply) before diving into the harder structural question.
Findings
Reconcile, clean, zero flips. gh api with state=open+labels=sergo returned exactly 4 opens: #65753 (sg87a1), #66009 (sg88a1), #66436 (sg89a1), #66773 (sg90a1), precisely matching R90s prediction. All 4 re-verified via direct code read: cgo.yml wasm LINTER_FLAGS (line 1552) still omits -contextcancelnotdeferred while the native line (1528) includes it; globwalkignorederror.go:34 still registers an AssignStmt-only nodeFilter via astutil.MatchDiscardedErrorCall; reflect_deepequal_usage.go still requires call.Fun to be a direct SelectorExpr so an aliased reflect.DeepEqual value still escapes; coverage.go hitCount (103-111) is still line-only / column-blind.
New-explore 1, ShouldApply call-site audit (clean). Read every one of the 15 call sites of coverage.ShouldApply across the gated linters. In every case the position passed for gating matches the position used for the actual report, including mapclearloop, which deliberately gates on the loop bodys position rather than the for headers position. Confirmed via gh api this was an intentional fix landed via closed issue #53031 (gating on the header would never suppress a loop that never iterates, since the header always executes once reached). This whole vein is now audited clean across all 15 linters.
New-explore 2, mapclearloop.sameObject paren gap (too weak to file). sameObjects comparison helper takes its ref argument without first unwrapping a ParenExpr, so a loop written as for k := range (m) { delete(m, k) } would escape detection. This reproduces the exact judgment call R76 already made for this same linter (nobody writes a parenthesized builtin-call-shape argument in practice), reconfirmed, not filed.
New-explore 3, coverage.findProfile suffix-match nondeterminism (filed as sg91a1). findProfile (coverage.go:81-98) iterates the profile map and returns on the first key whose value satisfies a plain substring-suffix check, with no preference for the longest or most specific match. Because Go map iteration order is randomized per process, two files whose module-relative paths sit in a suffix relationship (e.g. linters/foo.go vs pkg/linters/foo.go) could have their coverage profiles nondeterministically swapped. Confirmed via gh api that this is a different root cause from the closed #52566 / #52309 (that was a pure no-match false-negative, fixed by adding the module-relative comparison that this new finding lives inside) and from the closed #53031 referenced above. No live colliding file pair was found in the current tree via targeted Glob spot-checks (types.go, config.go, registry.go), so this is filed as a latent structural risk on the same evidentiary basis as last runs sg90a1.
Generated task
Fix coverage.findProfile to prefer exact or longest matches over first-suffix-match (sg91a1, filed): replace the suffix scan with either an exact match against the module-relative-normalized key, or (if cross-module suffix matching must be kept) a collect-all-candidates-then-prefer-longest strategy. Validation: a regression test with two synthetic profile keys in a suffix relationship, asserting the correct one is always returned regardless of map insertion order.
Metrics
Total runs: 91 (avg success score 8.71 over history; 8 this run)
Total findings to date: 554, total tasks: 158
Issues filed this run: 1 (budget up to 3), 7th consecutive single-issue run (R73/R81/R87/R88/R89/R90/R91), consistent with the established depth-over-padding pattern when reconcile plus cached-vein verification find nothing to refile.
Historical context
This is the 3rd consecutive run probing pkg/linters/internal/coverage (ADR-51573): R90 found the hitCount line/column blindness, R91 completed the ShouldApply call-site sweep (clean) and found the findProfile suffix-match risk. Both coverage-package bugs remain fully latent since GH_AW_LINT_COVERAGE_PROFILE is never set in any CI workflow. The packages new-explore backlog is now effectively exhausted at these two findings plus the clean call-site sweep.
If the registry grows to 78, audit the new linter fresh.
The coverage package has no more unprobed surface identified right now, next run should pick a fresh never-solo-audited linter, or resume the non-linter-logic CI-config sweep rotation (cgo.yml / doc_sync_test.go) per R87s standing recommendation.
Tooling note: a plain Bash pipe/awk/sort attempt at an exhaustive repo-wide path-suffix-collision scan was denied outright by the sandboxs permission layer this run (broader than the previously known jq/mkdir class), future runs should plan on Glob-based spot-checks for this kind of cross-file search rather than shell scripting.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Executive summary
Run R91 reconciled cleanly against GitHub (zero reverse-phantom flips, a first in several runs), re-verified all 4 previously filed findings are still accurate via direct code reads, and filed one new issue: a latent nondeterminism bug in the same dormant coverage-gating package that produced last runs finding. Registry and Serena tooling are both stable, so the full exploration budget went into the coverage package and a from-scratch audit of gate-vs-report position alignment across all 15 coverage-gated linters.
Tool and registry updates
Strategy split (50/50)
Cached reuse (50%): reconcile GitHub state for the 4 open sergo issues first, then re-verify each ones underlying code is still accurate (not just trust the open/closed label) before deciding whether anything needed refiling.
New exploration (50%): follow up on R90s own suggested next step, the coverage.findProfile path-matching logic, but first sanity-check the easier half of that area (whether any of the 15 gated linters pass a mismatched position into ShouldApply) before diving into the harder structural question.
Findings
Reconcile, clean, zero flips. gh api with state=open+labels=sergo returned exactly 4 opens: #65753 (sg87a1), #66009 (sg88a1), #66436 (sg89a1), #66773 (sg90a1), precisely matching R90s prediction. All 4 re-verified via direct code read: cgo.yml wasm LINTER_FLAGS (line 1552) still omits -contextcancelnotdeferred while the native line (1528) includes it; globwalkignorederror.go:34 still registers an AssignStmt-only nodeFilter via astutil.MatchDiscardedErrorCall; reflect_deepequal_usage.go still requires call.Fun to be a direct SelectorExpr so an aliased reflect.DeepEqual value still escapes; coverage.go hitCount (103-111) is still line-only / column-blind.
New-explore 1, ShouldApply call-site audit (clean). Read every one of the 15 call sites of coverage.ShouldApply across the gated linters. In every case the position passed for gating matches the position used for the actual report, including mapclearloop, which deliberately gates on the loop bodys position rather than the for headers position. Confirmed via gh api this was an intentional fix landed via closed issue #53031 (gating on the header would never suppress a loop that never iterates, since the header always executes once reached). This whole vein is now audited clean across all 15 linters.
New-explore 2, mapclearloop.sameObject paren gap (too weak to file). sameObjects comparison helper takes its ref argument without first unwrapping a ParenExpr, so a loop written as for k := range (m) { delete(m, k) } would escape detection. This reproduces the exact judgment call R76 already made for this same linter (nobody writes a parenthesized builtin-call-shape argument in practice), reconfirmed, not filed.
New-explore 3, coverage.findProfile suffix-match nondeterminism (filed as sg91a1). findProfile (coverage.go:81-98) iterates the profile map and returns on the first key whose value satisfies a plain substring-suffix check, with no preference for the longest or most specific match. Because Go map iteration order is randomized per process, two files whose module-relative paths sit in a suffix relationship (e.g. linters/foo.go vs pkg/linters/foo.go) could have their coverage profiles nondeterministically swapped. Confirmed via gh api that this is a different root cause from the closed #52566 / #52309 (that was a pure no-match false-negative, fixed by adding the module-relative comparison that this new finding lives inside) and from the closed #53031 referenced above. No live colliding file pair was found in the current tree via targeted Glob spot-checks (types.go, config.go, registry.go), so this is filed as a latent structural risk on the same evidentiary basis as last runs sg90a1.
Generated task
Metrics
Historical context
This is the 3rd consecutive run probing pkg/linters/internal/coverage (ADR-51573): R90 found the hitCount line/column blindness, R91 completed the ShouldApply call-site sweep (clean) and found the findProfile suffix-match risk. Both coverage-package bugs remain fully latent since GH_AW_LINT_COVERAGE_PROFILE is never set in any CI workflow. The packages new-explore backlog is now effectively exhausted at these two findings plus the clean call-site sweep.
Recommendations and next-run focus
References:
§ 37881444302
All reactions