Skip to content

gh aw logs requests unsupported path JSON field from gh run list, then misclassifies the error as an authentication failure #20679

@rabo-unumed

Description

@rabo-unumed

The summary below reflects a recurring error experienced on a remote development environment (ssh).

My CLI versions:

  • gh aw version v0.57.2
  • gh version 2.88.1 (2026-03-12)

The error report is written by Copilot as a I am not familiar with the codebase - I did try to guide it. The described errors match the ones I observed and initially inquired about.

Summary

gh aw logs fails with a misleading error:

✗ GitHub CLI authentication required. Run 'gh auth login' first

…even though the user is fully authenticated (confirmed via gh auth status). The actual problem is that gh-aw requests a path JSON field from gh run list --json that does not exist in the GitHub CLI.

Root Cause

There are two bugs:

Bug 1: path is not a valid gh run list --json field

In listWorkflowRunsWithPagination, the command requests:

args := []string{"run", "list", "--json", "databaseId,number,url,status,conclusion,workflowName,path,createdAt,startedAt,updatedAt,event,headBranch,headSha,displayTitle"}

However, the gh CLI's RunFields has never included path. The valid fields are:

name, displayTitle, headBranch, headSha, createdAt, updatedAt, startedAt,
attempt, status, conclusion, event, number, databaseId, workflowDatabaseId,
workflowName, url

This causes gh to output:

🔍 Unknown JSON field: "path"

Notably, a regression test comment in logs_github_api_test.go acknowledges a prior issue with this field:

// Regression: commit 61cc2d7ac (Jan 4 2026) silently dropped "path" from the
// gh run list --json field list, causing WorkflowPath to always be "" and the
// .lock.yml filter in fetchWorkflowRuns to discard every run.

This suggests path was intentionally re-added to the gh-aw field list to fix a filtering regression — but the field was never actually supported by the gh CLI. It may have worked in some environments where gh silently ignored unknown fields, but it fails in environments where gh rejects them.

Bug 2: Error misclassification (case-sensitive string matching + overly broad heuristic)

The error handling in listWorkflowRunsWithPagination checks for invalid field errors before auth errors, which is correct in principle:

if strings.Contains(combinedMsg, "invalid field") ||
    strings.Contains(combinedMsg, "unknown field") ||
    strings.Contains(combinedMsg, "field not found") ||
    strings.Contains(combinedMsg, "no such field") {
    return nil, 0, fmt.Errorf("invalid field in JSON query ...")
}

However, the gh CLI outputs "Unknown JSON field" (capital U), and strings.Contains is case-sensitive in Go. So "unknown field" does not match "Unknown JSON field", and the check is skipped.

The code then falls through to the auth error check:

if strings.Contains(combinedMsg, "exit status 4") ||
    strings.Contains(combinedMsg, "exit status 1") ||
    ...

The "exit status 1" heuristic matches because gh run list exits with code 1 on the invalid field error, so the user sees a completely wrong "authentication required" message.

Steps to Reproduce

  1. Use any standard version of the GitHub CLI (gh).
  2. Run gh aw logs -vvv.
  3. Observe:
    • The verbose output shows 🔍 Unknown JSON field: "path"
    • But the final error says ✗ GitHub CLI authentication required. Run 'gh auth login' first
    • gh auth status confirms you are authenticated.

Expected Behavior

  • gh-aw should not request JSON fields that the gh CLI does not support.
  • If an unsupported field is requested and rejected, the error message should clearly indicate the incompatibility (e.g., "Unsupported JSON field 'path'. You may need to upgrade your gh CLI.") rather than claiming an authentication failure.

Proposed Fix

  1. Remove path from the gh run list --json field list (or replace it with an alternative approach to get the workflow file path, such as using the REST API or workflowDatabaseId).
  2. Make error substring checks case-insensitive (e.g., use strings.Contains(strings.ToLower(combinedMsg), "unknown field")).
  3. Narrow the "exit status 1" heuristic — this is too broad and catches non-auth errors. Consider removing it or only matching when combined with auth-specific keywords.

References

Metadata

Metadata

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions