[sergo] Sergo Report: CI Config Sweep and Fix Verification - 2026-10-05 #65754
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Sergo - Serena Go Expert. A newer discussion is available at Discussion #66010. |
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
Registry and Serena tool counts are both stable (76 analyzers, 24 Serena tools). The open sergo issue backlog dropped to zero this run: a maintainer bulk-closed all 14 issues from the R74-R86 reconcile sweeps (13 confirmed landed-fixed, plus the timenowsub refile from the previous run) and cleaned up one junk test-probe issue. With nothing left to reconcile, this run spent its budget verifying the recent fixes hold up and sweeping a part of the codebase never swept before: the CI workflow configuration itself. That surfaced one confirmed, still-unfixed reverse-phantom bug, filed as a single new issue.
Tool and registry status
serena --help.grep -c Analyzer,$ pkg/linters/registry.go), unchanged since R85 (fprintferrorunchecked, PR [linter-miner] Add fprintf-error-unchecked linter #65073).Strategy: 50/50 cached vs new split
Cached component (verification, not refiling): with zero opens to reconcile, the usual refile work from the bounded 3-run memory window did not apply. Instead, re-read
pkg/linters/internal/resourcetracker/resourcetracker.goandpkg/linters/bufioscannererunchecked/bufioscannererunchecked.goend to end to stress-test the fixes landed since R85/R86 (the per-acquisition-position state map in resourcetracker, and therest-threading in bufioscannererunchecked). Both held up under harder scenarios (branch-local reassignment, nested blocks) - audited clean, no regression found.New-exploration component: a first-ever full diff of
.github/workflows/cgo.ymlnative vs wasmLINTER_FLAGSstrings (previously only spot-checked per newly-added linter, never swept end-to-end). This is new ground: no prior run had compared the two lists directly against each other.Finding: contextcancelnotdeferred missing from wasm CI enforcement
The native custom-linter CI step and the
GOOS=js GOARCH=wasmstep run the same linter suite with two separately-maintainedLINTER_FLAGSstrings that are supposed to be identical (modulo the wasm-onlyLINTER_PACKAGESscoping). They are, except for one flag:-contextcancelnotdeferredappears in the native string only.This turned out to be a rediscovery, not a new finding: issue #55932 (temporary_id sg61a1) filed this exact gap on 2026-08-26 and auto-expired closed not_planned on 2026-09-02, without ever being fixed. It was never refiled in the 25 runs since, because the topic (CI workflow config) never happened to fall inside any single runs bounded 3-entry strategy-memory window - a blind spot in how this workflow samples its own history. Re-reading the current file confirms the gap is still present today, more than five weeks and dozens of edits later.
The root cause traces to the introducing commit (PR #49783, 2026-08-02), which added both
contextcancelnotdeferredandwgdonenotdeferredto the native list but only addedwgdonenotdeferredto the wasm list - a copy-paste omission at the moment the linter was introduced. It also was not caught by the dedicated drift-prevention test (TestCIEnforcedLintersMatchRegistryinpkg/linters/doc_sync_test.go, added by issue #55636 specifically to guard registry-to-CI drift): that test unions bothLINTER_FLAGSmatches into a single set before checking registry membership, so an analyzer enforced on only one of the two build targets still satisfies the check. The guard cannot detect this class of asymmetry by construction.Impact is currently latent - no
*_wasm.gofile under the 5 wasm-linted packages usescontext.WithCancel/WithTimeout/WithDeadlinetoday - but any future wasm-only code using a cancellable context and a manual (non-deferred) cancel would pass CI silently on both targets.Filed as a single issue (sg87a1) recommending both the one-line
cgo.ymlfix and hardening the drift-guard test to assert set equality between the twoLINTER_FLAGSlists, not just their union.Generated tasks
-contextcancelnotdeferredto the wasmLINTER_FLAGSstring incgo.yml, and extendTestCIEnforcedLintersMatchRegistryto assert the native and wasm flag sets are identical (modulo-test=falseandLINTER_PACKAGES) so this class of drift cannot silently reappear.Metrics this run
Historical context
87 runs total, 537 cumulative findings, 154 cumulative tasks, running average success score 8.73. This is the first run in recent history to reconcile against a fully empty open-issue backlog - the previous standing veins (paren_unwrap_gap, branch_state_merge, presnapshot_position_blind, idiom_reflag_no_allowlist, block_scope_state_reset, ident_only_equality_gap) all closed out in the R86 sweep. A new pattern class, ci_target_asymmetry, has been added to the shared pattern catalog.
Recommendations for maintainers
Next-run focus (R88)
Verify sg87a1 landed. Expect exactly one open sergo issue at reconcile start - the cleanest slate in this workflows history. If the linter registry grows past 76, audit the new linter fresh; otherwise continue rotating cgo.yml/doc.go consistency sweeps alongside the usual per-linter bug hunts.
References
All reactions