Summary
The set_issue_type handler's GraphQL intent path (enabled when issue_intents runtime feature is active) has two bugs that cause it to fail at runtime:
-
Wrong query scope: fetchIssueTypesForOrg queries organization(login: $owner) { issueTypes } which requires organization-level read permissions that typical app tokens don't have. This results in "Resource not accessible by integration".
-
Wrong field name in mutation input: setIssueTypeById builds the IssueTypeUpdateInput object with { id: issueTypeId } but the GraphQL schema expects { issueTypeId: ... }.
Fix
-
Replace the organization-level query with a repository-level query:
fetchIssueTypesForOrg(githubClient, owner) → fetchIssueTypesForRepo(githubClient, owner, repo)
- Query:
repository(owner: $owner, name: $repo) { issueTypes(first: 100) { nodes { id name } } }
- This only requires
issues: write permission which is already granted.
-
Fix the mutation input field:
const issueType = { id: issueTypeId, ...intentMetadata } → const issueType = { issueTypeId, ...intentMetadata }
Example working GraphQL queries
Fetching issue types (repository-level)
query($owner: String!, $repo: String!) {
repository(owner: $owner, name: $repo) {
issueTypes(first: 100) {
nodes {
id
name
}
}
}
}
Setting issue type with intent metadata
mutation($issueId: ID!, $issueType: IssueTypeUpdateInput!) {
updateIssue(input: { id: $issueId, issueType: $issueType }) {
issue {
id
}
}
}
With variables:
{
"issueId": "<issue node ID>",
"issueType": {
"issueTypeId": "<issue type node ID>",
"rationale": "Author explicitly describes a bug",
"confidence": "HIGH",
"suggest": true
}
}
Note: The request must include the GraphQL-Features: update_issue_suggestions header.
Affected files
actions/setup/js/set_issue_type.cjs
actions/setup/js/set_issue_type.test.cjs
Verification
Both fixes were validated end-to-end in a live workflow run with issue_intents enabled in a sandbox environment. The handler successfully resolved issue types from the repository and set the type via the GraphQL mutation with the correct IssueTypeUpdateInput shape.
Summary
The
set_issue_typehandler's GraphQL intent path (enabled whenissue_intentsruntime feature is active) has two bugs that cause it to fail at runtime:Wrong query scope:
fetchIssueTypesForOrgqueriesorganization(login: $owner) { issueTypes }which requires organization-level read permissions that typical app tokens don't have. This results in "Resource not accessible by integration".Wrong field name in mutation input:
setIssueTypeByIdbuilds theIssueTypeUpdateInputobject with{ id: issueTypeId }but the GraphQL schema expects{ issueTypeId: ... }.Fix
Replace the organization-level query with a repository-level query:
fetchIssueTypesForOrg(githubClient, owner)→fetchIssueTypesForRepo(githubClient, owner, repo)repository(owner: $owner, name: $repo) { issueTypes(first: 100) { nodes { id name } } }issues: writepermission which is already granted.Fix the mutation input field:
const issueType = { id: issueTypeId, ...intentMetadata }→const issueType = { issueTypeId, ...intentMetadata }Example working GraphQL queries
Fetching issue types (repository-level)
Setting issue type with intent metadata
With variables:
{ "issueId": "<issue node ID>", "issueType": { "issueTypeId": "<issue type node ID>", "rationale": "Author explicitly describes a bug", "confidence": "HIGH", "suggest": true } }Note: The request must include the
GraphQL-Features: update_issue_suggestionsheader.Affected files
actions/setup/js/set_issue_type.cjsactions/setup/js/set_issue_type.test.cjsVerification
Both fixes were validated end-to-end in a live workflow run with
issue_intentsenabled in a sandbox environment. The handler successfully resolved issue types from the repository and set the type via the GraphQL mutation with the correctIssueTypeUpdateInputshape.