[CI Failure Doctor] Runtime setup regression keeps default Python override in lock file

[github-actions]

🏥 CI Failure Investigation - Run #34128

Summary

Integration: Workflow Runtime & Setup is failing because TestRuntimeSetupPreservesUserVersions now sees the default Python 3.12 setup step reinserted even though the workflow frontmatter pins python-version: '3.9'. The compiler is no longer deduplicating the runtime step that the user already defined, so the lock file ends up containing 3.12 and the test assertion at pkg/workflow/runtime_setup_integration_test.go:292‑305 trips.

Failure Details

• Run: 21764804244
• Commit: 5d14550befbdf3ec76b4c614dc6fe98aeba70513
• Trigger: push

Root Cause Analysis

DetectRuntimeRequirements still adds a Python requirement whenever a run: python … command is present, and GenerateRuntimeSetupSteps renders that runtime using the default version (3.12). The deduplication pass (DeduplicateRuntimeSetupStepsFromCustomSteps in pkg/workflow/runtime_deduplication.go) is supposed to notice when the user already exercised actions/setup-python and filter that runtime out, but that filter is no longer taking effect for the integration test case, so the compiler reinserts python-version: '3.12' after the user’s pinned step.

Failed Jobs and Errors

• Integration: Workflow Runtime & Setup: TestRuntimeSetupPreservesUserVersions fails with runtime_setup_integration_test.go:299: Should not override user's version with default version (the lock file unexpectedly contains 3.12).

Investigation Findings

• The failing test in pkg/workflow/runtime_setup_integration_test.go explicitly asserts that the lock file must retain the user-supplied python-version: '3.9' and must not contain the default (3.12).
• Runtime detection + deduplication (pkg/workflow/runtime_detection.go and pkg/workflow/runtime_deduplication.go) should filter out any runtime requirement that is already satisfied by a custom uses: actions/setup-python step, but that filtering no longer happens in this scenario.
• As a result, the generated lock file now contains two Setup Python steps (the user’s custom one and the generated one), and the default version leaks into the lock file, tripping the integration test.

Recommended Actions

• Verify and harden DeduplicateRuntimeSetupStepsFromCustomSteps so that it detects user-specified python-version overrides (even when the user pins a commit SHA) and removes the automatic runtime requirement before GenerateRuntimeSetupSteps runs.
• Add or update regression coverage that inspects the compiled lock file to ensure no default versions appear alongside a user-provided setup step (the existing TestRuntimeSetupPreservesUserVersions should continue to guard this scenario).
• Confirm the runtime detection path still sees custom steps (the test workflow runs python test.py), so that runtimeRequirements stays in sync with what deduplication expects.

Prevention Strategies

Ensure future changes to runtime detection/deduplication continue to respect explicit actions/setup-* steps by exercising the integration test suite and guarding the 3.12 absence assertion in the lock file; add a lint or golden-check that catches duplicate runtime steps when a user explicitly includes one.

AI Team Self-Improvement

• When modifying runtime detection or deduplication logic, rerun pkg/workflow integration tests (especially TestRuntimeSetupPreservesUserVersions) before merging.
• Double-check that lock-file assertions continue to catch accidental reinsertion of default versions.

Historical Context

No cached investigations under /tmp/memory/investigations/ matched this failure, so it appears to be a new regression triggered by the AWF v0.13.12 update.

AI generated by CI Failure Doctor

To add this workflow in your repository, run gh aw add githubnext/agentics/workflows/ci-doctor.md@ea350161ad5dcc9624cf510f134c6a9e39a6f94d. See usage guide.

• expires on Feb 7, 2026, 8:40 PM UTC