[aw] Linter Miner failed

[github-actions]

Workflow Failure

Workflow: Linter Miner
Branch: main
Run: https://github.com/github/gh-aw/actions/runs/32508657133

Warning

Invalid or Unsupported Model: The agent failed because the configured model name is invalid, unknown, or unavailable for this engine/account.

This is a configuration issue, not a transient error — retrying will not help.

How to fix this

Specify a valid model for the selected engine in the workflow frontmatter:

---
engine: copilot
model: gpt-5-mini
---

To find valid models, check your engine/provider documentation (for Copilot see supported models).

If the error text is No model available. Check policy enablement under GitHub Settings > Copilot, the model is not disabled in the workflow but by Copilot policy. Enable the model under GitHub Settings > Copilot > Policies for the org/repo, or pick a model that is already enabled. This can also be triggered by a subagent (task tool) dispatch requesting a model that the policy does not allow, even when the main agent's model is enabled.

Warning

Engine Failure: The copilot engine terminated unexpectedly.

Last agent output:

{"type":"tool.execution_complete","timestamp":"2026-08-21T17:37:10.923Z","data":{"toolName":"view","mcpServerName":"","success":true,"result":{"content":"1. ---\n2. name: go-linters\n3. description: Add and validate custom Go analysis linters in gh-aw.\n4. ---\n5. \n6. # Go Linters\n7. \n8. Use this guide when adding a new custom Go analysis linter in this repository.\n9. \n10. For PR-driven linter generation (derive a rule from a specific pull request pattern), use `.github/skills/pr-to-go-linter/SKILL.md`.\n11. \n12. ## Where to add a new linter\n13. \n14. 1. Create a new package under `pkg/linters/<linter-name>/`.\n15. 2. Define an analyzer in that package (exported as `Analyzer`).\n16. 3. Add tests in the same package using `analysistest` with fixtures under `testdata/src/...`.\n17. 4. Register the analyzer in `cmd/linters/main.go` so it runs via the multichecker binary.\n18. \n19. ## Build and test linters\n20. \n21. - Test only your linter package:\n22.   - `go test ./pkg/linters/<linter-name>/...`\n23. - Build the custom linter runner:\n24.   - `go build ./cmd/linters`\n25. - Run all custom linters across the repo:\n26.   - `make golint-custom`\n27. \n28. `make golint-custom` builds `cmd/linters` and runs it against `./cmd/...` and `./pkg/...`.\n29. \n30. ## Coverage-aware perf gating\n31. \n32. For linters that flag micro-optimizations (allocation/perf rules), only apply them on lines that\n33. tests actually exercise — \"hot paths\" — rather than on dead or rarely-executed code where the\n34. optimization brings no measurable benefit. Use the shared `pkg/linters/internal/coverage` package:\n35. \n36. 1. In your analyzer file, register a `-hot-threshold` flag in `init()` (not as a var initializer,\n37.    to avoid an `Analyzer`/`run`/flag initialization cycle):\n38. \n39.    ```go\n40.    var hotThreshold *int\n41. \n42.    func init() {\n43.        hotThreshold = coverage.RegisterHotThresholdFlag(Analyzer)\n44.    }\n45.    ```\n46. \n47. 2. Immediately before reporting a diagnostic, gate it with `coverage.ShouldApply`:\n48. \n49.    ```go\n50.    if !coverage.ShouldApply(pass, node.Pos(), *hotThreshold) {\n51.        return\n52.    }\n53.    ```\n54. \n55. `coverage.ShouldApply` is permissive by default: when no coverage profile is loaded via the\n56. `GH_AW_LINT_COVERAGE_PROFILE` environment variable, or when `hot-threshold` is `0`, it always\n57. returns `true`, preserving pre-coverage-aware behavior. Only wire this into linters whose fix has\n58. a genuine performance rationale (extra allocations, O(n²) behavior, etc.) — purely\n59. readability/style linters should not be coverage-gated.\n60. \n61. ### Generating the coverage profile\n62. \n63. ```bash\n64. go test -covermode=count -coverprofile=/tmp/coverage.out ./...\n65. export GH_AW_LINT_COVERAGE_PROFILE=/tmp/coverage.out\n66. make golint-custom\n67. ```\n68. \n69. This profile is read once per linter-runner process. To lint only a specific subtree, scope\n70. the `go test` and `golint-custom` commands to the same package path.\n71. ","detailedContent":"\ndiff --git a/tmp/gh-aw/agent/go-linters-skill.txt b/tmp/gh-aw/agent/go-linters-skill.txt\nindex 0000000..0000000 100644\n--- a/tmp/gh-aw/agent/go-linters-skill.txt\n+++ b/tmp/gh-aw/agent/go-linters-skill.txt\n@@ -1,71 +1,71 @@\n ---\n name: go-linters\n description: Add and validate custom Go analysis linters in gh-aw.\n ---\n \n # Go Linters\n \n Use this guide when adding a new custom Go analysis linter in this repository.\n \n For PR-driven linter generation (derive a rule from a specific pull request pattern), use `.github/skills/pr-to-go-linter/SKILL.md`.\n \n ## Where to add a new linter\n \n 1. Create a new package under `pkg/linters/<linter-name>/`.\n 2. Define an analyzer in that package (exported as `Analyzer`).\n 3. Add tests in the same package using `analysistest` with fixtures under `testdata/src/...`.\n 4. Register the analyzer in `cmd/linters/main.go` so it runs via the multichecker binary.\n \n ## Build and test linters\n \n - Test only your linter package:\n   - `go test ./pkg/linters/<linter-name>/...`\n - Build the custom linter runner:\n   - `go build ./cmd/linters`\n - Run all custom linters across the repo:\n   - `make golint-custom`\n \n `make golint-custom` builds `cmd/linters` and runs it against `./cmd/...` and `./pkg/...`.\n \n ## Coverage-aware perf gating\n \n For linters that flag micro-optimizations (allocation/perf rules), only apply them on lines that\n tests actually exercise — \"hot paths\" — rather than on dead or rarely-executed code where the\n optimization brings no measurable benefit. Use the shared `pkg/linters/internal/coverage` package:\n \n 1. In your analyzer file, register a `-hot-threshold` flag in `init()` (not as a var initializer,\n    to avoid an `Analyzer`/`run`/flag initialization cycle):\n \n    ```go\n    var hotThreshold *int\n \n    func init() {\n        hotThreshold = coverage.RegisterHotThresholdFlag(Analyzer)\n    }\n    ```\n \n 2. Immediately before reporting a diagnostic, gate it with `coverage.ShouldApply`:\n \n    ```go\n    if !coverage.ShouldApply(pass, node.Pos(), *hotThreshold) {\n        return\n    }\n    ```\n \n `coverage.ShouldApply` is permissive by default: when no coverage profile is loaded via the\n `GH_AW_LINT_COVERAGE_PROFILE` environment variable, or when `hot-threshold` is `0`, it always\n returns `true`, preserving pre-coverage-aware behavior. Only wire this into linters whose fix has\n a genuine performance rationale (extra allocations, O(n²) behavior, etc.) — purely\n readability/style linters should not be coverage-gated.\n \n ### Generating the coverage profile\n \n ```bash\n go test -covermode=count -coverprofile=/tmp/coverage.out ./...\n export GH_AW_LINT_COVERAGE_PROFILE=/tmp/coverage.out\n make golint-custom\n ```\n \n This profile is read once per linter-runner process. To lint only a specific subtree, scope\n the `go test` and `golint-custom` commands to the same package path.\n \n"}}}
{"type":"assistant.message","timestamp":"2026-08-21T17:37:43.108Z","data":{"content":"Now let's launch the linter-writer sub-agent to implement it."}}
{"type":"tool.execution_start","timestamp":"2026-08-21T17:37:43.110Z","data":{"toolName":"task","mcpServerName":""}}
{"type":"subagent.started","timestamp":"2026-08-21T17:37:43.128Z","data":{"agentName":"general-purpose","agentDisplayName":"General Purpose Agent","toolCallId":"toolu_01FNNZGyZWHU3qw4bjWrZRVB"}}
[copilot-sdk-driver] [sdk-driver] error: Execution failed: Error: No model available. Check policy enablement under GitHub Settings > Copilot
{"type":"subagent.completed","timestamp":"2026-08-21T17:37:43.191Z","data":{"agentName":"general-purpose","toolCallId":"toolu_01FNNZGyZWHU3qw4bjWrZRVB"}}
{"type":"tool.execution_complete","timestamp":"2026-08-21T17:37:43.221Z","data":{"toolName":"task","mcpServerName":"","success":false}}
{"type":"subagent.completed","timestamp":"2026-08-21T17:37:43.234Z","data":{"agentName":"research","toolCallId":"toolu_018yTKGaUYzxAf5Q5A2X4ffq"}}
{"type":"subagent.completed","timestamp":"2026-08-21T17:37:43.235Z","data":{"agentName":"explore","toolCallId":"toolu_013SJoS8KDvMgQHcQvwMAHyr"}}
{"type":"subagent.completed","timestamp":"2026-08-21T17:37:43.237Z","data":{"agentName":"general-purpose","toolCallId":"toolu_01FNNZGyZWHU3qw4bjWrZRVB"}}

Action Required

Assign this issue to an agent to debug and fix the issue.

Debug with any coding agent

Use this prompt with any coding agent (GitHub Copilot, Claude, Gemini, etc.):

Debug the agentic workflow failure using https://raw.githubusercontent.com/github/gh-aw/main/debug.md

The failed workflow run is at https://github.com/github/gh-aw/actions/runs/32508657133

Manually invoke the agent

Debug this workflow failure using your favorite Agent CLI and the agentic-workflows prompt.

• Start your agent
• Load the agentic-workflows skill from .github/skills/agentic-workflows/SKILL.md or https://github.com/github/gh-aw/blob/main/.github/skills/agentic-workflows/SKILL.md
• Type debug the agentic workflow linter-miner failure in https://github.com/github/gh-aw/actions/runs/32508657133

Tip

Stop reporting this workflow as a failure

To stop a workflow from creating failure issues, set report-failure-as-issue: false in its frontmatter:

safe-outputs:
  report-failure-as-issue: false

Generated from Linter Miner · 44.1 AIC · ◷

• expires on Aug 22, 2026, 5:39 AM UTC