github_branch_default: 422 Unprocessable Entity

[dee-kryvenko]

Terraform Version

{
  "terraform_version": "0.14.0",
  "terraform_revision": "",
  "provider_selections": {
    "registry.terraform.io/hashicorp/github": "4.1.0"
  },
  "terraform_outdated": false
}

Affected Resource(s)

• github_branch_default

Terraform Configuration Files

resource "github_branch_default" "this" {
  repository = github_repository.this.name
  branch     = github_branch.this.branch
}

Debug Output

https://gist.github.com/dee-kryvenko/7cc5b517ef72ce4f87ee63aec5d178b0

Expected Behavior

Should have set default branch successfully.

Actual Behavior

Fails to do so.

Steps to Reproduce

1. terraform apply

Important Factoids

I managed to narrow it down via curl to the following header: Accept: application/vnd.github.baptiste-preview+json, application/vnd.github.nebula-preview+json. It seems like if I remove application/vnd.github.nebula-preview+json part from my headers - it works. As it is used for the visibility field as described here https://docs.github.com/en/free-pro-team@latest/rest/reference/repos, I have tried to experiment with this field and it seems to only work if I set visibility: public. It fails as described above for both private and internal - so, unable to reproduce on a free org. It might be an issue with GitHub - I am currently talking to the Enterprise support and will update here with their findings.

References

• github_branch_default *always* returns 422 Visibility is already private. [] on deletion #620 - might be another symptom of the same issue?

[javed7891]

I am facing this same issue & also the one mentioned in #620.

[Gowiem]

I have had a project run into this as well as soon as we upgraded and started using this resource. Would be interested in the fix for this awesome new resource!

[dee-kryvenko]

To be honest I do not believe there's any issues with a resource at this point. This really looks like a GitHub API bug. I just created this ticket so that we have a place to communicate. GitHub Enterprise support still haven't got back to me even though I ping them weekly. They say they are working on reproducing the issue (it's a simple curl request, c'mon). Maybe they are awaiting for more signals from the community that it is a wide spread issue - I don't know.

[Gowiem]

@dee-kryvenko ah interesting. Thanks for sharing the context and good luck with hashing it out with them!

[timmehhh7]

Facing this as well... Can't modify the default branch for private repos. @dee-kryvenko if there is an issue you can reference folks can maybe weigh in there as well to help GH understand how wide-spread it is?

Thanks!
Tim

[dee-kryvenko]

I'm talking to them via their Enterprise support plan through my employer. I don't think these tickets are public. There's no updates on this BTW.
Maybe we should look for ways to reach out to them publicly. Any ideas on what that might be?

[dee-kryvenko]

I finally got an update from GitHub support. Seems that it is indeed a bug in the provider, though the error message returned by API is a little bit off but more on that later.

It seems like this provider currently sends the whole repository JSON as a body to the PATCH request. It turns out it supposed to only be sending fields that did changed, i.e. for github_branch_default resource particularly the request should look like the following:

curl https://api.github.com/repos/xxx/yyy \
  -u username:${GITHUB_TOKEN} \
  -X PATCH \
  -H 'Accept: application/vnd.github.baptiste-preview+json, application/vnd.github.nebula-preview+json' \
  -d '{"default_branch": "master"}'

I tested and this request indeed works fine, even though it includes application/vnd.github.nebula-preview+json part in the Accept header. Changing visibility field works that way too.

It seems like this provider needs to be doing a better job in terms of identifying which fields did change and be sending only that changed fields.

It seems like sending everything worked fine before, but something is different about this new visibility field and the header that enables it. It seems like a combination of application/vnd.github.nebula-preview+json presence along with unchanged visibility field in case it was either private or internal but not public in the request triggers this error, which sounds like a bug or at the very least a backward incompatible change, and the error message it returns doesn't makes any sense. I've sent two additional questions to the GitHub rep:

1. It seems like before introducing that visibility field along with that application/vnd.github.nebula-preview+json header - the API worked fine even when the whole mostly-unchanged repository object JSON was sent to the PATCH endpoint. Even though that behavior wasn't explicitly documented, the opposite wasn't documented either. I would imagine GitHub Terraform provider is not the only one using the API that way, so depends on the point of view it might or might not be considered a backward incompatible change. Could you clarify please what's the official GitHub stance on that, and will that be explicitly documented as not supported scenario or maybe your team would consider adding this as a new supported scenario?

2. The error message it returns ("The branch master was not found. Please push that ref first or create it via the Git Data API.") is definitely wrong. The branch did existed and the message didn't help at all with the troubleshooting. I don't think without this support ticket anyone would been able to figure this out, especially that the documentation doesn't say explicitly that I can't send unchanged fields back to the API. I think it definitely needs fixing.

I'll pass along their feedback when I get it, regardless now we know that the issue is on the provider side and we know what needs to be fixed.

The code for github_branch_default seems to be pretty straight forward briefly looking into it. Sounds like we just need to remove Get call before calling Edit and ad-hoc creating a body object instead. That should also probably fix #620. I might be able to send a PR fixing it shortly. But it sounded like we have more places broken that way, if so - that will not automatically fix these.

[dee-kryvenko]

Alright, unless I'm missing something - that should be the fix #666
Love the 666 number of it.

[dee-kryvenko]

@jcudit would you be able please to take a look?

[jcudit]

Will do! Thanks for your persistence here.