gh pr merge --auto --squash --delete-branch Errors withGraphQL: Field 'isMergeQueueEnabled' doesn't exist on type 'PullRequest'

[dwise1056]

The bug

Attempting to merge a PR change and delete the contributing branch does not work when using fined-grained tokens.

This issue occurs on our enterprise cloud EMU instance, using gh CLI v2.42.1

Steps to reproduce the behavior

Executing the following command:
gh pr merge --auto --squash --delete-branch ${pr_url}

Returns the following error
GraphQL: Field 'isMergeQueueEnabled' doesn't exist on type 'PullRequest' (query PullRequestByNumber.repository.pullRequest.isMergeQueueEnabled)

The merge occasionally works for some Org repositories. The delete-branch never works for any repositories.

The following commands have no issue
gh pr create --title "${WIP_ID} ${pr_added_title}" --body-file "${WORKSPACE}/${WIP_ID}_pr_body" --base ${target_branch}
gh pr edit ${pr_number} --add-reviewer ${REVIEWER_ID}
gh pr review --approve ${pr_number} --body "$WIP_ID ${pr_noun} by $REQUESTOR
Executed by ${JOB_AUTOMATION}"

Expected vs actual behavior

The expected behaviour is that the approved PR will be merged and the contributing branch deleted.

Logs

It appears the issue is related to recent GitHub changes regarding fined-grained tokens and Org level rulesets. Our issue coincided with updating tokens used by an automated process. The new tokens were created as fine-grained tokens, and assigned more permissions than should be needed to perform the merge and delete.

I did find a work around that resolved impact to our automation for all our repositories. I created a legacy token (classic), and that token has no issue executing the merge and delete-branch. It does exactly what is expected. The legacy token (classic) worked for the 2 repository configurations that are shared below.

Below are differences between our least affected repository and a repository affected 100% of the time.

There was a lot of inconsistency when using a fined-grained token. The error happens to some repositories more than others. Repositories with advanced security enabled seem to encounter this less. These same repositories do not appear to inherit rulesets created at the Org level.

Here are diffs between a repository intermittently affected vs one affected 100% of the time (when using fined-grained tokens).

Repository intermittently affected
from ${GITHUB_API_BASE_URL}/orgs/${ORG_OWNER}/repos
"security_and_analysis": {
"advanced_security": {
"status": "enabled"
},
"secret_scanning": {
"status": "enabled"
},

from ${GITHUB_API_BASE_URL}/repos/${ORG_OWNER}/${REPO_NAME}/branches/${BASE_BRANCH}/protection"
no differences between the 2 repositories. the API confirms they are exactly the same

${GITHUB_API_BASE_URL}/repos/${GITHUB_ORG_OWNER}/${REPO_NAME}/rulesets/rule-suites
Returns nothing. There are no rulesets created at the repo level. We apply org level rulessets. Those rulesets do not appear in the returned API for advanced security enabled repositories.

Repository always affected
from ${GITHUB_API_BASE_URL}/orgs/${ORG_OWNER}/repos
"security_and_analysis": {
"advanced_security": {
"status": "disabled"
},
"secret_scanning": {
"status": "disabled"
},

from ${GITHUB_API_BASE_URL}/repos/${ORG_OWNER}/${REPO_NAME}/branches/${BASE_BRANCH}/protection"
The below ruleset shows up in this API return. The ruleset is created at the org level for all repositories.
"ref": "refs/heads/${BASE_BRANCH}",
"result": "pass",
"evaluation_result": "fail"

${GITHUB_API_BASE_URL}/repos/${GITHUB_ORG_OWNER}/${REPO_NAME}/rulesets/rule-suites/${rule_suite_id}
"ref": "refs/heads/${BASE_BRANCH}",
"result": "pass",
"evaluation_result": "fail"
"rule_evaluations": [
{
"rule_source": {
"type": "ruleset",
},
"enforcement": "evaluate",
"result": "fail",
"rule_type": "pull_request",
"details": "Changes must be made through a pull request."
},
{
"rule_source": {
"type": "ruleset",
},
"enforcement": "evaluate",
"result": "pass",
"rule_type": "non_fast_forward"
},
{
"rule_source": {
"type": "ruleset",
},
"enforcement": "evaluate",
"result": "pass",
"rule_type": "deletion"
}

[williammartin]

Thanks for creating this separately, just leaving a comment here that this appears to be distinct from the bug that was shipped yesterday in case anyone else comes to triage it before I get to it.

[williammartin]

@dwise1056 before I dig into this, the Merge Queue team made a few fields API fields public that were previously feature flagged and I think a lot of weird token edge cases are going to be resolved as a result. Could you double check that actions that you would expect to fail are still failing?

[andyfeller]

@dwise1056 before I dig into this, the Merge Queue team made a few fields API fields public that were previously feature flagged and I think a lot of weird token edge cases are going to be resolved as a result. Could you double check that actions that you would expect to fail are still failing?

@dwise1056 : have you had an opportunity to follow up on ☝️ ?

[williammartin]

Pretty sure this was fixed and it's gone stale so I'm closing it. Feel free to reopen if there is still an issue.