Analysis: compiler downgrade (v0.87.1, PR #1999) impact on AW executions — root-caused pre-existing setup-uv bug, not the downgrade

[v1v]

Context

PR #1999 temporarily downgraded the gh-aw compiler from v0.87.10 to v0.87.1 (see #1998 for the rationale — bypassing threat-detection engine failures). This issue documents the post-downgrade verification analysis and proposes next steps.

What was checked

1. Are all AWs consistently referencing main?

Yes. All workflows in this repo dogfood themselves via trigger-*.yml → uses: ./.github/workflows/<name>.lock.yml (relative reusable-workflow refs). Relative refs always resolve to the ref of the calling run, and all triggers (schedule / workflow_dispatch) run on the default branch. No inconsistency found. (Downstream-facing templates in gh-agent-workflows/*/example.yml intentionally pin @v0 — that's by design for external consumers, not an oversight.)

2. Did any new/organic runs surface a downgrade-related regression?

No organic agent runs occurred in the window immediately after the merge (only CI + 2 skipped workflow_run triggers). To get signal, 6 representative dispatchable workflows were manually triggered:

Workflow	Result
Bug Hunter	✅ success
Docs Patrol	✅ success
Stale Issues Investigator	✅ success
Project Summary	✅ success
Code Complexity Detector	❌ failed
Code Duplication Detector	❌ failed

A later scheduled run of Stale Issues Investigator (run 33772080263) also completed successfully.

3. Root cause of the 2 failures

Both fail at the Expose uv in workspace step:

UV_PATH: 
ln: failed to create symbolic link '/opt/hostedtoolcache/gh-aw-tools/current/x64/bin/uv' -> '': No such file or directory
##[error]Process completed with exit code 1

UV_PATH is sourced from steps.setup-uv.outputs.uv-path, but the preceding Setup uv step (astral-sh/setup-uv@v10.0.1) in these two lock files has no id: setup-uv, so the output reference resolves to empty.

Confirmed NOT caused by the v0.87.1 downgrade: diffing gh-aw-code-complexity-detector.lock.yml and gh-aw-code-duplication-detector.lock.yml before/after PR #1999, this exact section (Setup uv step + Expose uv in workspace step) is byte-identical across both compiler versions. Workflows using the older astral-sh/setup-uv@v5 path (Bug Hunter, Docs Patrol, Stale Issues Investigator, Project Summary) are unaffected — only workflows that import the gh-aw-fragments/code-quality-audit.md fragment (which pulls in the v10.0.1 action pinning) hit this.

This is a pre-existing, already-tracked recurring bug, not a downgrade regression:

• [aw] Code Duplication Detector failed #1996, [aw] Code Complexity Detector failed #1987, [aw] Code Complexity Detector failed #1956 — "[aw] Code Complexity Detector failed"
• [aw] Code Duplication Detector failed #1985, [aw] Code Duplication Detector failed #1954 — "[aw] Code Duplication Detector failed"
• [agent-efficiency] Recurring setup-uv failure pattern across last-7-day failed agent workflow runs #1982 — "Recurring setup-uv failure pattern across last-7-day failed agent workflow runs"
• [agent-efficiency] Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out #1991 — "Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out" (deep root-cause writeup, same signature, also flags a cascading conclusion-job artifact-download failure once the detector step aborts)

Conclusion

No breakage attributable to the v0.87.1 downgrade was found. The compiler downgrade itself appears safe to keep in place. The only failures observed are a known, unrelated setup-uv output-id bug affecting workflows built from the code-quality-audit.md fragment.

Proposed next steps (for further analysis / fix)

• Add id: setup-uv to the Setup uv step (astral-sh/setup-uv@v10.0.1) wherever the compiler template emits the "Expose uv in workspace" step, so steps.setup-uv.outputs.uv-path resolves correctly. Determine whether this needs to be fixed upstream in github/gh-aw (compiler template) or can be patched locally.
• Fix the cascading conclusion-job failure (Unable to download artifact(s): Artifact not found for name: <id>-detection) that occurs when the detector step aborts before producing its detection artifact — the conclusion job should tolerate a missing artifact gracefully instead of hard-failing.
• Once fixed, confirm the github/gh-aw upstream release that eventually replaces this temporary v0.87.1 pin also carries the fix, so re-upgrading doesn't reintroduce it.
• Consider consolidating the recurring auto-filed [aw] Code Complexity/Duplication Detector failed issues ([aw] Code Duplication Detector failed #1996, [aw] Code Complexity Detector failed #1987, [aw] Code Duplication Detector failed #1985, [aw] Code Complexity Detector failed #1956, [aw] Code Duplication Detector failed #1954, [agent-efficiency] Recurring setup-uv failure pattern across last-7-day failed agent workflow runs #1982, [agent-efficiency] Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out #1991) once the root cause is fixed, to avoid further duplicate noise.

[v1v]

/ai I want you to analyse why id: setup-uv is missing when suing the gh-aw version v0.87.1 and whether a new version in https://github.com/github/gh-aw has a fix.

Run make compile to see if the id: setup-uv is fixed.

Otherwise, make a proposal so it can be solvd using the gh-aw rather than doing anything in the generated .lock files.

[github-actions]

3 related issues

• [agent-efficiency] Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out #1991 — it documents the same setup-uv/empty UV_PATH failure signature plus the follow-on missing detection artifact behavior, which supports the root-cause analysis in this issue.
• [agent-efficiency] Recurring setup-uv failure pattern across last-7-day failed agent workflow runs #1982 — it aggregates repeated occurrences of the same setup-uv symlink failure pattern across recent runs, providing broader recurrence evidence.
• [aw] Code Duplication Detector failed #1996 — it is another current instance of the same detector failure mode, useful as a fresh repro datapoint while tracking recurrence.

---

What is this? | From workflow: Trigger Duplicate Issue Detector

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[github-actions]

tl;dr I recommend treating this as not a downgrade regression: the observed failures match a pre-existing setup-uv wiring failure pattern that was already present before PR #1999 merged.

Recommendation
Keep the current conclusion in #2007: PR #1999 (compiler pin downgrade to v0.87.1) is not the proximate cause of the failing AW executions. Prioritize fixing the setup-uv output wiring + conclusion artifact handling path, then re-evaluate re-upgrade timing separately.

Findings

1. Timeline supports pre-existing failure

   • PR chore(gh-aw): temporarily downgrade compiler to v0.87.1 #1999 merged at 2026-09-03T14:14:04Z: chore(gh-aw): temporarily downgrade compiler to v0.87.1 #1999
   • Same failure family was already documented before merge:
     • [agent-efficiency] Recurring setup-uv failure pattern across last-7-day failed agent workflow runs #1982 (2026-09-01T15:57:40Z): recurring empty UV_PATH / symlink failure pattern
     • [agent-efficiency] Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out #1991 (2026-09-02T15:46:00Z): same setup failure and conclusion artifact cascade

2. Source-level workflow wiring indicates shared/runtime pattern, not issue-specific logic drift

   • .github/workflows/gh-aw-fragments/runtime-setup.md:38 defines id: setup-uv
   • .github/workflows/gh-aw-fragments/runtime-setup.md:44 consumes steps.setup-uv.outputs.uv-path
   • This same pattern appears broadly in generated lock files, indicating template/runtime emission behavior rather than a unique codepath introduced by chore(gh-aw): temporarily downgrade compiler to v0.87.1 #1999.

3. Downgrade scope is pin+recompile, not targeted runtime-setup redesign

   • Makefile:4-6 contains compiler pin values (GH_AW_VERSION, GH_AW_BUILD_VERSION, GH_AW_COMPAT_VERSION) now at v0.87.1.
   • No evidence found that chore(gh-aw): temporarily downgrade compiler to v0.87.1 #1999 introduced a new authored setup-uv contract mismatch unique to these workflows.

Verification

I validated with:

rg -n "id:\s*setup-uv|steps\.setup-uv\.outputs\.uv-path" .github/workflows/gh-aw-fragments/runtime-setup.md
rg -n "id:\s*setup-uv|steps\.setup-uv\.outputs\.uv-path" .github/workflows/*.lock.yml

Key observed matches:

• .github/workflows/gh-aw-fragments/runtime-setup.md:38
• .github/workflows/gh-aw-fragments/runtime-setup.md:44
• Representative lock-file propagation (example): .github/workflows/gh-aw-issue-triage.lock.yml:597 and :602

And GitHub metadata timeline correlation from:

• [agent-efficiency] Recurring setup-uv failure pattern across last-7-day failed agent workflow runs #1982, [agent-efficiency] Recurring workflow failures from missing uv artifact in agent setup and conclusion artifact fan-out #1991, Analysis: compiler downgrade (v0.87.1, PR #1999) impact on AW executions — root-caused pre-existing setup-uv bug, not the downgrade #2007, PR chore(gh-aw): temporarily downgrade compiler to v0.87.1 #1999

Detailed Action Plan

1. Fix setup-uv contract in workflow generation/runtime path

   • Audit where Setup uv and Expose uv in workspace are emitted together.
   • Ensure output producer/consumer alignment is guaranteed (if consumer uses steps.setup-uv.outputs.uv-path, producer must always be id: setup-uv and action version/output contract must match).
   • Primary authored entrypoint to inspect first: .github/workflows/gh-aw-fragments/runtime-setup.md and any upstream compiler templates referenced by it.

2. Harden conclusion artifact download behavior

   • Update conclusion logic so missing *-detection artifact after early detector abort is handled gracefully (skip/soft-fail path with explicit reason), rather than hard failing fan-out.

3. Regenerate + validate workflows

   • Re-run compile pipeline and confirm affected detector workflows no longer fail in setup stage.
   • Re-test at least code-complexity-detector and code-duplication-detector trigger workflows.

4. Re-upgrade strategy

   • Keep temporary downgrade until threat-detection upstream fix and setup-uv/conclusion robustness are both validated.
   • Then perform a controlled compiler re-upgrade and re-check representative detectors.

Related Items

Type	Link	Relevance
Issue	#2007	Current analysis issue
PR	#1999	Compiler downgrade change
Issue	#1982	Pre-downgrade recurring setup-uv failure evidence
Issue	#1991	Pre-downgrade setup-uv + conclusion artifact cascade evidence
File	.github/workflows/gh-aw-fragments/runtime-setup.md	Source of setup-uv id/output wiring pattern
File	Makefile	Compiler version pin definitions

---

What is this? | From workflow: Trigger Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[github-actions]

The missing id: setup-uv is not caused by using gh-aw v0.87.1; after running make compile in this repo, the problem is still present specifically in the two lockfiles tied to code-quality audit import paths.

Evidence from the freshly compiled workspace:

• .github/workflows/gh-aw-code-complexity-detector.lock.yml:539 has - name: Setup uv but no id: setup-uv, while later it references steps.setup-uv.outputs.uv-path (...:576) in Expose uv in workspace (...:578).
• .github/workflows/gh-aw-code-duplication-detector.lock.yml:539 has the same shape (missing id + downstream steps.setup-uv.outputs.uv-path reference).
• In contrast, many other compiled workflows do include id: setup-uv alongside the same Expose uv in workspace pattern.

Upstream status:

• Latest gh-aw release is now v0.88.2 (published 2026-09-03): https://github.com/github/gh-aw/releases/tag/v0.88.2
• I cannot verify from this environment whether v0.88.2 specifically fixes this template path, but based on local compile behavior with v0.87.1, the issue is clearly in compiler/template generation, not in hand-edited lockfiles.

Proposal (gh-aw-native, no lockfile patching):

1. Fix upstream in github/gh-aw where the Setup uv step is emitted for the code-quality audit / detector template path so it always sets id: setup-uv when later steps consume steps.setup-uv.outputs.uv-path.
2. Add a compiler regression test in github/gh-aw that compiles a minimal workflow using this path and asserts both:
   • name: Setup uv is present with id: setup-uv
   • any Expose uv in workspace step has a non-empty producer step for steps.setup-uv.outputs.uv-path
3. After upstream merge, bump this repo’s compiler pin and run make compile; the generated *.lock.yml should then self-heal without manual edits.

If useful, I can open a targeted PR in this repo that adds a CI guard (source-level validation) to fail when a generated lockfile references steps.setup-uv.outputs.uv-path without a matching id: setup-uv in the same job, preventing future regressions from landing.

---

What is this? | From workflow: Trigger Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

[v1v]

/ai wonder if https://github.com/elastic/ai-github-actions/edit/main/.github/workflows/gh-aw-fragments/runtime-setup.md could be the issue, and where the id should be set?

[github-actions]

Yes — runtime-setup.md is the right place to look, but the missing id is not in that fragment itself.

In this repo, .github/workflows/gh-aw-fragments/runtime-setup.md already defines:

• Setup uv with id: setup-uv at .github/workflows/gh-aw-fragments/runtime-setup.md:35-39
• Expose uv in workspace consuming steps.setup-uv.outputs.uv-path at .github/workflows/gh-aw-fragments/runtime-setup.md:40-45

So if generated lockfiles still show Setup uv without id (as seen in gh-aw-code-complexity-detector.lock.yml:539 and gh-aw-code-duplication-detector.lock.yml:539), that points to a compiler/template emission path dropping the id for those workflows, not a missing id in your local fragment source.

Where the id should be set: on the same Setup uv step that runs astral-sh/setup-uv, immediately under uses, exactly like:

- name: Setup uv
  if: hashFiles('pyproject.toml', 'uv.lock') != ''
  uses: astral-sh/setup-uv@v5
  id: setup-uv

If that step is emitted with @v10.0.1 in another template path, it still needs the same id: setup-uv whenever later steps reference steps.setup-uv.outputs.uv-path.

Given this, I’d file/fix upstream in github/gh-aw (compiler template), then recompile here; no manual .lock.yml edits needed.

---

What is this? | From workflow: Trigger Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.