integrations / integrations/terraform-provider-github

github_repository_file: read errors instead of removing the resource from state when its commit no longer exists

Open
#3,586 1 comment 0 reactions 0 assignees View on GitHub
r/repository_file Status: Triage Type: Bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.