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
error-message-lint.yml — the only CI workflow that runs the errormessage custom analyzer (pkg/linters/errormessage) against changed .go files on every PR — has been disabled_manually since 2026-05-20, after five consecutive failing runs that same day. It has not been re-enabled since, despite a full-repo audit and multi-PR remediation effort explicitly targeting errormessage violations completing on 2026-08-12. errormessage is documented as 1 of the "66 active analyzers" in pkg/linters/doc.go and is fully registered via linters.All(), but it currently has zero live CI enforcement of any kind — this is worse than the 13 other "unenforced but still executed via golint-custom" linters, because errormessage isn't in that allowlist either (see Evidence).
Evidence
gh api repos/github/gh-aw/actions/workflows/error-message-lint.yml → "state": "disabled_manually", "updated_at": "2026-05-20T03:22:13Z".
The 5 most recent runs of this workflow are all completed / failure, all timestamped 2026-05-20 (run IDs 26134896194...26138647305); no runs exist after that date. The Run errormessage linter on changed files step is the one that failed in the last run (job/step data still available via actions/runs/{id}/jobs); raw logs are gone (410 Gone, past the retention window).
The workflow (.github/workflows/error-message-lint.yml:54-58) is the only place in the repo that invokes -errormessage.changed-files=... (confirmed via grep -rn errormessage .github/). No other workflow references errormessage.
pkg/linters/errormessage is not in the LINTER_FLAGS allowlist used by make golint-custom in .github/workflows/cgo.yml:1372 / :1375 (the 52-name list that gates the host and wasm builds) — so it also never runs there, blocking or otherwise.
The only other invocation point, make lint-error-messages-report (Makefile:1032-1037, full-repo -errormessage.full-repo, non-blocking || true), is a local-only Make target — it is never called from any .github/workflows/*.yml.
Despite this, real remediation work already happened on the assumption the check would come back:
Net effect: the codebase was cleaned up in August specifically for this linter, but the gate that would keep it clean (and that would have caught the new-code style debt during the 3 intervening months) is still off.
Impact
Any .go file changed since 2026-05-20 can introduce errormessage violations (non-actionable "invalid/cannot/must/failed" messages without guidance, fmt.Errorf used in _validation.go files instead of NewValidationError, empty/example-less NewValidationError suggestions) with no CI signal at all — not even a non-blocking report, since the report target isn't wired into CI either.
The August remediation investment (1,129 violations found, ~8 PRs of fixes) has no regression protection going forward — new violations will silently accumulate again until the next manual full-repo audit.
This is a case the existing sergo "unenforced linter" pattern class doesn't fully capture: unlike the 14 linters merely absent from LINTER_FLAGS (which still get selectively enabled elsewhere or are read for metrics), errormessage has no live invocation path in CI whatsoever.
Suggested fix
Determine why the 5 runs failed on 2026-05-20 (root cause is not recoverable from logs — retention expired — but the size/pattern of the August violation cleanup, "1,129 violations", strongly suggests the workflow was simply red on real (pre-existing) violations in changed files, not an infra bug).
Re-enable the workflow: gh api -X PUT repos/github/gh-aw/actions/workflows/error-message-lint.yml/enable (or via repo Settings → Actions), then run it once via workflow_dispatch against current main to confirm it's clean post-cleanup before trusting it on PRs.
If it's still noisy, consider first wiring make lint-error-messages-report (already built, non-blocking) into cgo.yml as an interim report-only signal, then flipping error-message-lint.yml back to blocking once the report is clean — mirroring the enforce-readiness pattern already used for the other custom linters.
Validation checklist
Confirm error-message-lint.yml state after fix is active (gh api repos/github/gh-aw/actions/workflows/error-message-lint.yml --jq .state)
A workflow_dispatch run (full-repo, since it falls back to git ls-files outside pull_request) completes without the "Run errormessage linter on changed files" step failing
A subsequent PR touching a .go file shows the check running (not skipped/absent) in its status checks
Effort
Small — this is a re-enable + verify task, not a code change, unless step 1 surfaces a real bug in the analyzer itself.
Summary
error-message-lint.yml— the only CI workflow that runs theerrormessagecustom analyzer (pkg/linters/errormessage) against changed.gofiles on every PR — has beendisabled_manuallysince 2026-05-20, after five consecutive failing runs that same day. It has not been re-enabled since, despite a full-repo audit and multi-PR remediation effort explicitly targetingerrormessageviolations completing on 2026-08-12.errormessageis documented as 1 of the "66 active analyzers" inpkg/linters/doc.goand is fully registered vialinters.All(), but it currently has zero live CI enforcement of any kind — this is worse than the 13 other "unenforced but still executed viagolint-custom" linters, becauseerrormessageisn't in that allowlist either (see Evidence).Evidence
gh api repos/github/gh-aw/actions/workflows/error-message-lint.yml→"state": "disabled_manually","updated_at": "2026-05-20T03:22:13Z".completed/failure, all timestamped2026-05-20(run IDs26134896194...26138647305); no runs exist after that date. TheRun errormessage linter on changed filesstep is the one that failed in the last run (job/step data still available viaactions/runs/{id}/jobs); raw logs are gone (410 Gone, past the retention window)..github/workflows/error-message-lint.yml:54-58) is the only place in the repo that invokes-errormessage.changed-files=...(confirmed viagrep -rn errormessage .github/). No other workflow referenceserrormessage.pkg/linters/errormessageis not in theLINTER_FLAGSallowlist used bymake golint-customin.github/workflows/cgo.yml:1372/:1375(the 52-name list that gates the host and wasm builds) — so it also never runs there, blocking or otherwise.make lint-error-messages-report(Makefile:1032-1037, full-repo-errormessage.full-repo, non-blocking|| true), is a local-only Make target — it is never called from any.github/workflows/*.yml.[deep-report] Add full-repo audit mode to pkg/linters/errormessage, closed 2026-08-06) found 1,129 existing violations and added the-full-repomode used by the report target above.[squad-plan] Fix error message compliance: ...issues (e.g. [squad-plan] Fix error message compliance: checkout_config_parser.go, safe_outputs_data_schema.go, stop_after.go, model_identifier.go, engine [Content truncated due to length] #52165–[squad-plan] Fix error message compliance: dispatch_workflow_validation.go, dispatch_repository_validation.go, run_interactive.go, outcome_ev [Content truncated due to length] #52172, Fix error message compliance in runs_on_validation, frontmatter_extraction_metadata, reactions, call_workflow_validation, and ambient_folders #52177–Fix error message compliance in 5 pkg/workflow files #52180) were filed and closed between 2026-08-11 and 2026-08-12, fixing violations across dozens ofpkg/workflowandpkg/clifiles.Impact
.gofile changed since 2026-05-20 can introduceerrormessageviolations (non-actionable "invalid/cannot/must/failed" messages without guidance,fmt.Errorfused in_validation.gofiles instead ofNewValidationError, empty/example-lessNewValidationErrorsuggestions) with no CI signal at all — not even a non-blocking report, since the report target isn't wired into CI either.sergo"unenforced linter" pattern class doesn't fully capture: unlike the 14 linters merely absent fromLINTER_FLAGS(which still get selectively enabled elsewhere or are read for metrics),errormessagehas no live invocation path in CI whatsoever.Suggested fix
gh api -X PUT repos/github/gh-aw/actions/workflows/error-message-lint.yml/enable(or via repo Settings → Actions), then run it once viaworkflow_dispatchagainst currentmainto confirm it's clean post-cleanup before trusting it on PRs.make lint-error-messages-report(already built, non-blocking) intocgo.ymlas an interim report-only signal, then flippingerror-message-lint.ymlback to blocking once the report is clean — mirroring the enforce-readiness pattern already used for the other custom linters.Validation checklist
error-message-lint.ymlstate after fix isactive(gh api repos/github/gh-aw/actions/workflows/error-message-lint.yml --jq .state)workflow_dispatchrun (full-repo, since it falls back togit ls-filesoutsidepull_request) completes without the "Run errormessage linter on changed files" step failing.gofile shows the check running (not skipped/absent) in its status checksEffort
Small — this is a re-enable + verify task, not a code change, unless step 1 surfaces a real bug in the analyzer itself.
Location
.github/workflows/error-message-lint.yml(disabled workflow).github/workflows/cgo.yml:1372,:1375(LINTER_FLAGS allowlist,errormessageabsent)Makefile:1032-1037(unused report-only target)pkg/linters/errormessage/errormessage.go(the dormant analyzer)