set_issue_field cannot discover issue fields because its GraphQL query is invalid for IssueFields

[h3y6e]

Summary

set_issue_field currently skips all issue field updates when issue fields are present and visible, because its discovery query is no longer valid against the current GitHub GraphQL schema.

The handler reports:

No issue fields were discovered for this repository. Verify issue fields are enabled and visible to this token.

but the underlying problem is a GraphQL validation error, not missing fields.

Root cause

fetchIssueFields() in actions/setup/js/set_issue_field.cjs queries IssueFields.nodes like this:

nodes {
  __typename
  id
  name
  ... on IssueFieldSingleSelect {
    options { id name }
  }
}

IssueFields is a union, so id and name cannot be selected directly. They need to be selected inside concrete type fragments.

The same query also includes:

... on User {
  issueFields(first: 100) { ... }
}

but User.issueFields is not present in the current schema.

Reproducing the current query with gh api graphql returns:

Selections can't be made directly on unions (see selections on IssueFields)
Field 'issueFields' doesn't exist on type 'User'

fetchIssueFields() catches that error and returns [], which makes the handler incorrectly treat the failure as "no fields discovered".

Expected behavior

When issue fields exist, set_issue_field should discover them and apply the requested value.

When discovery fails because of a GraphQL/schema/permission error, the handler should surface that error instead of converting it into a skipped "no fields discovered" result.

Proposed fix

Update fetchIssueFields() in actions/setup/js/set_issue_field.cjs to query concrete IssueFields union members, for example:

nodes {
  __typename
  ... on IssueFieldText { id name }
  ... on IssueFieldNumber { id name }
  ... on IssueFieldDate { id name }
  ... on IssueFieldSingleSelect { id name options { id name } }
  ... on IssueFieldMultiSelect { id name options { id name } }
}

Also remove the invalid ... on User { issueFields } branch. Keep the repository-level lookup and, if still needed, the Organization.issueFields fallback.

Implementation plan

1. Fix the GraphQL query in actions/setup/js/set_issue_field.cjs.
2. Make fetchIssueFields() distinguish between:
   • successful query with zero fields, which can still skip gracefully;
   • GraphQL/schema/permission failure, which should return an actionable error.
3. Clarify the field_node_id behavior. The current tool description says it can skip discovery, but the implementation still requires discovery to resolve field type and validate the ID.
4. Add tests in actions/setup/js/set_issue_field.test.cjs for:
   • concrete fragments on IssueFields;
   • no direct id/name selection on the union;
   • no User.issueFields selection;
   • GraphQL discovery errors are not reported as "No issue fields were discovered";
   • successful empty discovery still skips gracefully.
5. Update generated tool metadata/docs if the field_node_id wording changes.
6. Run the project validation, including make agent-finish.

Versions checked

• gh-aw: v0.79.6
• gh-aw-actions: v0.79.7

The same invalid discovery query is present in the latest checked release artifacts.

[h3y6e]

I tried this again with v0.79.8, which includes #38882. It looks like one invalid fragment remains in actions/setup/js/set_issue_field.cjs:

... on IssueField {
  id
  name
}

The current GitHub GraphQL schema does not define IssueField; introspection returns null for __type(name: "IssueField"). As a result, any query containing that fragment fails with:

No such type IssueField, so it can't be a fragment condition

This failure happens during field discovery, before any field update mutation is attempted. If I remove only the generic IssueField fragment, the discovery query validates and returns fields.