integrations / integrations/terraform-provider-github
github_repository_file: read errors instead of removing the resource from state when its commit no longer exists
- Dominant language
- Go
- Stars
- 1.2k
- Forks
- 1k
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 8
Description
### Summary
`github_repository_file`'s read returns a hard error instead of removing the resource from state when the commit it recorded is no longer reachable — for example because the repository, the branch, or the relevant history is gone.
### Current behaviour
`resourceGithubRepositoryFileRead` looks the file's commit up via `client.Repositories.GetCommit` (when `commit_sha` is in state) or `getFileCommit` (when it is not). Both error paths fall through to a bare `return diag.FromErr(err)`:
- a GitHub **404** from `GetCommit` is surfaced as a read failure
- `getFileCommit` returns `cannot find file %s in repo %s/%s` when no commit reachable from the ref contains the file, which is likewise surfaced as a read failure
Other resources in the provider already handle this correctly. `resource_github_repository_custom_property.go`, `resource_github_repository_ruleset.go` and `resource_github_branch_default.go` all detect a 404 on read and call `d.SetId("")` so the resource is removed from state.
### Why this matters
Terraform's contract for read is that a missing remote object means "clear the ID", not "fail". Because this resource errors instead, once the underlying commit is unreachable the resource can neither be refreshed nor cleanly removed — every subsequent plan/apply fails on the read, and the entry cannot be reconciled away without manual state surgery.
The effect is more pronounced for consumers that drive this provider through a reconciliation loop rather than a one-shot `terraform apply`, since a read that always errors is retried indefinitely.
### Expected behaviour
A read that establishes the file's commit no longer exists should remove the resource from state (`d.SetId("")`, no error), consistent with the other repository resources listed above. Errors that are not "not found" should keep propagating unchanged.
I have a patch for this and will open a PR shortly.
🤖
Contributor guide
Research direction
Start in the implementation of resourceGithubRepositoryFileRead and compare its GetCommit and getFileCommit error handling with resource_github_repository_custom_property.go, resource_github_repository_ruleset.go, and resource_github_branch_default.go. Confirm the not-found cases clear the resource ID without an error while other errors still propagate, then run the repository file resource tests if available.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, go, terraform
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 30/100