Summary
The set_issue_field handler's fetchIssueFields function includes an organization-level fallback query (repository.owner { ... on Organization { issueFields } }) that causes the entire GraphQL request to fail with "Resource not accessible by integration" when using the GITHUB_TOKEN (Actions installation token).
This is the same pattern that was fixed for set_issue_type in #42227 / v0.82.0.
Root cause
fetchIssueFields (line 44–87 of set_issue_field.cjs) builds a single GraphQL query that requests both repository-level and organization-level issue fields:
query($owner: String!, $repo: String!) {
repository(owner: $owner, name: $repo) {
issueFields(first: 100) {
nodes { ... }
}
owner {
__typename
... on Organization {
issueFields(first: 100) {
nodes { ... }
}
}
}
}
}
The repository.owner { ... on Organization { issueFields } } part requires organization-level permissions that the GITHUB_TOKEN does not have. Because GraphQL evaluates the entire query, the org-level fragment causes the whole request to fail — the repository-level fields are never returned.
The handler then falls through with zero fields discovered, and all set_issue_field calls silently skip (before v0.82.0) or fail (v0.82.0+).
Fix
Remove the organization-level fallback from fetchIssueFields and query only repository-level fields:
async function fetchIssueFields(githubClient, owner, repo) {
const result = await githubClient.graphql(
`query($owner: String!, $repo: String!) {
repository(owner: $owner, name: $repo) {
issueFields(first: 100) {
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 } }
}
}
}
}`,
{ owner, repo }
);
const isValidNode = node => typeof node?.id === "string" && typeof node?.name === "string";
return (result?.repository?.issueFields?.nodes ?? []).filter(isValidNode);
}
The dead-code for ownerFields (lines 85–86) should also be removed.
Example working GraphQL query
Fetching issue fields (repository-level only)
query($owner: String!, $repo: String!) {
repository(owner: $owner, name: $repo) {
issueFields(first: 100) {
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 } }
}
}
}
}
This query only requires issues: write permission, which is already granted to the GITHUB_TOKEN.
Setting an issue field value (already works)
mutation($issueId: ID!, $fieldValues: [IssueFieldCreateOrUpdateInput!]!) {
setIssueFieldValues(input: { issueId: $issueId, fieldValues: $fieldValues }) {
issue { id }
}
}
With variables:
{
"issueId": "<issue node ID>",
"fieldValues": [
{
"fieldId": "<field node ID>",
"singleSelectOptionId": "<option node ID>"
}
]
}
Note: The setIssueFieldValue / setIssueFieldValues mutation itself works fine with GITHUB_TOKEN — only the fetch query is broken.
Affected files
actions/setup/js/set_issue_field.cjs — remove org-level fallback from fetchIssueFields
actions/setup/js/set_issue_field.test.cjs — update tests to remove org-level expectations
Verification
The fix was validated end-to-end by patching the bundled set_issue_field.cjs in a sandbox workflow lock file to remove the org-level query at runtime. All four set_issue_field calls completed successfully after the patch:
✓ Message 3 (set_issue_field) completed successfully
✓ Message 4 (set_issue_field) completed successfully
✓ Message 5 (set_issue_field) completed successfully
✓ Message 6 (set_issue_field) completed successfully
Prior to the patch, the same workflow consistently failed with "Resource not accessible by integration" on every set_issue_field call.
Summary
The
set_issue_fieldhandler'sfetchIssueFieldsfunction includes an organization-level fallback query (repository.owner { ... on Organization { issueFields } }) that causes the entire GraphQL request to fail with "Resource not accessible by integration" when using theGITHUB_TOKEN(Actions installation token).This is the same pattern that was fixed for
set_issue_typein #42227 / v0.82.0.Root cause
fetchIssueFields(line 44–87 ofset_issue_field.cjs) builds a single GraphQL query that requests both repository-level and organization-level issue fields:The
repository.owner { ... on Organization { issueFields } }part requires organization-level permissions that theGITHUB_TOKENdoes not have. Because GraphQL evaluates the entire query, the org-level fragment causes the whole request to fail — the repository-level fields are never returned.The handler then falls through with zero fields discovered, and all
set_issue_fieldcalls silently skip (before v0.82.0) or fail (v0.82.0+).Fix
Remove the organization-level fallback from
fetchIssueFieldsand query only repository-level fields:The dead-code for
ownerFields(lines 85–86) should also be removed.Example working GraphQL query
Fetching issue fields (repository-level only)
This query only requires
issues: writepermission, which is already granted to theGITHUB_TOKEN.Setting an issue field value (already works)
With variables:
{ "issueId": "<issue node ID>", "fieldValues": [ { "fieldId": "<field node ID>", "singleSelectOptionId": "<option node ID>" } ] }Note: The
setIssueFieldValue/setIssueFieldValuesmutation itself works fine withGITHUB_TOKEN— only the fetch query is broken.Affected files
actions/setup/js/set_issue_field.cjs— remove org-level fallback fromfetchIssueFieldsactions/setup/js/set_issue_field.test.cjs— update tests to remove org-level expectationsVerification
The fix was validated end-to-end by patching the bundled
set_issue_field.cjsin a sandbox workflow lock file to remove the org-level query at runtime. All fourset_issue_fieldcalls completed successfully after the patch:Prior to the patch, the same workflow consistently failed with "Resource not accessible by integration" on every
set_issue_fieldcall.