[BUG]: Provider produced inconsistent result after apply (v6.7.3)

[avivamei]

Relates to: #2804

Expected Behavior

Provider should apply successfully

Actual Behavior

Provider fails during apply with error:

Provider produced inconsistent result after apply When applying changes to , provider "provider["registry.terraform.io/integrations/github"]" produced an unexpected new value: Root object was present, but now absent.

This is a bug in the provider, which should be reported in the provider's own issue tracker.

Terraform Version

Terraform v1.13.4 on linux_amd64

• provider registry.terraform.io/integrations/github v6.7.3

Affected Resource(s)

github_actions_secret

Terraform Configuration Files

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "~> 6.7"
    }
  }
}

resource "github_actions_secret" "secrets" {
  for_each = var.action_secrets
  repository      = github_repository.repo.name
  secret_name     = each.key
  plaintext_value = each.value
}

Steps to Reproduce

• Use GitHub provider version 6.7.3
• Define a github_actions_secret resource in your configuration
• Run terraform init
• Run terraform plan

Debug Output

Panic Output

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[dominictarro]

Same issue starting today.

[JamesGoodhouse-at]

Likely duplicate of https://github.com/integrations/terraform-provider-github/issues/2838 and https://github.com/integrations/terraform-provider-github/issues/2839

[avivamei]

Likely duplicate of #2838 and #2839

The errors in those issues seem to be resolved with v6.7.3, but I am getting different errors with v6.7.3

[rohitpaulk]

Running into the same here with a github actions secret resource.

[pnancarrow]

does this have anyone else completely stuck? I can't downgrade or I end up with:

 Error: Resource instance managed by newer provider version

[dominictarro]

does this have anyone else completely stuck? I can't downgrade or I end up with:

I downgraded to =6.7.0 and had to reimport a bunch of resources.

[nickfloyd]

So sorry for the trouble here. I think I've tracked down the issue to the Update implementation.

Turns out when a Terraform resource has an Update function defined (which was recently added), the Terraform SDK requires that any field that can change must either have ForceNew: true (meaning changes require resource recreation) or for that field to be a computed-only field.

The destroy_on_drift field is a provider config setting that controls how drift detection works - it's not a field that maps to the GitHub API. When implementations try to change this field Terraform will execute the plan properly ✅ but fail on the apply because the Update function didn't know how to handle the destroy_on_drift change.

You should be able to work around this issue while I work up a patch by pinning to v6.7.1 though that even looks problematic for some.

Working on a patch right away. Again apologies for the trouble.

[pnancarrow]

thanks! @nickfloyd

I also downgraded to 6.7.0 and had to do some state clean-up in the meantime.

[nickfloyd]

This is what I am thinking as a solution: https://github.com/integrations/terraform-provider-github/compare/v6.7.3...v6.7.4-patch - turns out the same problem existed on selected_repository_ids (this is a historical bug that wasn't present until Update was added).

[nickfloyd]

After a load of testing, validation, and discussion with @stevehipwell ❤️ I have released v6.7.4 with the fixes for this issue. Please let me know if you run into any issues.

[AndrewUnderwoodAtFanatics]

Unfortunately v6.7.4 made things worse for us, now the failure occours at the beginning of the plan instead of at the end of the apply.

I've opened https://github.com/integrations/terraform-provider-github/issues/2855

[eyalgal]

This issue should be fixed with v6.7.5

[Doug-Murphy]

I updated this morning to 6.7.5 and my initial issues are still happening unfortunately.

The TF plan showed the following:

Terraform will perform the following actions:

  # module.my_repo.github_repository_environment_deployment_policy.environment_deployment_policies["prod-master"] will be created
  + resource "github_repository_environment_deployment_policy" "environment_deployment_policies" {
      + branch_pattern = "master"
      + environment    = "prod"
      + id             = (known after apply)
      + repository     = "my-repo"
    }

I checked the repo settings, and this deployment policy already existed. I went ahead and tried to apply anyway to see if it'll just kinda rectify the statefile or whatever, but I got the following error:

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.my_repo.github_repository_environment_deployment_policy.environment_deployment_policies["prod-master"],
│ provider "provider[\"registry.terraform.io/integrations/github\"]" produced
│ an unexpected new value: Root object was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

I went into the repo settings and manually deleted it, then did another apply. The plan produced the same, but the apply worked this time. This leads me to believe the change detection may be having some issues with determine create vs update since it thought that the resource needed to be created even though it already existed?

Happy to open a new issue if that makes more sense. Decided to add as a reply to this since the error message is the same and the version is so close.

[ilmax]

I am also hitting a problem with secrets, using newly released version 6.8, this is the plan:

# module.organization.github_actions_organization_secret.secret["SUBSCRIPTION_ID"] will be updated in-place
  ~ resource "github_actions_organization_secret" "secret" {
      + destroy_on_drift        = true
        id                      = "SUBSCRIPTION_ID"
        # (6 unchanged attributes hidden)
    }

│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to module.organization.github_actions_organization_secret.secret["SUBSCRIPTION_ID"], provider "provider[\"registry.opentofu.org/integrations/github\"]" produced an unexpected new value: root object was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Not sure if this is the same bug or a different one tho

[nickfloyd]

Thank you for the additional info. I keep swinging at this one and while some situations get a little better, some folks are still having problems - which is why I'm a bit hesitant to make any more changes until I can get a definitive picture of what is actually going on.

After taking a look at this and the Terraform docs this morning the only thing I can come up with so far is we need to add ForceNew on the destroy_on_drift prop here and here.

"destroy_on_drift": {
    Type:        schema.TypeBool,
    Default:     true,
    Optional:    true,
    ForceNew:    true,  // ADD THIS
    Description: "Boolean indicating whether to recreate the secret if it's modified outside of Terraform.",
},

I need to do some more testing to get a more clear picture of what is actually going on but if anyone has time to 👀 that would be great as well.

[stevehipwell]

I think this behaviour may be being caused by the call to read from within the create function.

[vkpetrov]

Hello @nickfloyd! In our organization, we have switched to a fork from nexthink/oss. I have raised a pull request to fix this in a forked provider: https://github.com/nexthink-oss/terraform-provider-github/pull/13.

I can start a pull request for this integration if you are okay with this. The solution was tested and confirmed working. Please let me know. Thanks!

[deiga]

I updated this morning to 6.7.5 and my initial issues are still happening unfortunately.

The TF plan showed the following:

Terraform will perform the following actions:

  # module.my_repo.github_repository_environment_deployment_policy.environment_deployment_policies["prod-master"] will be created
  + resource "github_repository_environment_deployment_policy" "environment_deployment_policies" {
      + branch_pattern = "master"
      + environment    = "prod"
      + id             = (known after apply)
      + repository     = "my-repo"
    }

I checked the repo settings, and this deployment policy already existed. I went ahead and tried to apply anyway to see if it'll just kinda rectify the statefile or whatever, but I got the following error:

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.my_repo.github_repository_environment_deployment_policy.environment_deployment_policies["prod-master"],
│ provider "provider[\"registry.terraform.io/integrations/github\"]" produced
│ an unexpected new value: Root object was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

I went into the repo settings and manually deleted it, then did another apply. The plan produced the same, but the apply worked this time. This leads me to believe the change detection may be having some issues with determine create vs update since it thought that the resource needed to be created even though it already existed?

Happy to open a new issue if that makes more sense. Decided to add as a reply to this since the error message is the same and the version is so close.

@Doug-Murphy Did that resource already exist in Terraform before?

The behaviour you described, sounds like trying to add new TF code for already existing cloud resources. In such cases you must usually run Terraform import or use the import block

[Doug-Murphy]

@Doug-Murphy Did that resource already exist in Terraform before?

The behaviour you described, sounds like trying to add new TF code for already existing cloud resources. In such cases you must usually run Terraform import or use the import block

I don't recall if it already existed or not in the TF state. Since it was trying to create it, I would assume it didn't. However, it should have been in the TF state because the TF module we have is the only way our engineers could've made it. It should've been impossible to create it manually via ClickOps.

Regardless of that, this issue never cropped up for us in the past until we upgraded from v5 to v6. Nothing else had changed on our end. I don't recall what v5 we were on, or what v6 we initially stated with at the time of upgrade.

And lastly, the refreshing nature of the TF plan/apply should've accounted for the resource already existing IMO if it did already exist.

[Doug-Murphy]

I just hit this again. Documenting it while the data is fresh and I have the exact configuration!

Error message upon apply:

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ module.<repo-name>.github_repository_environment_deployment_policy.environment_deployment_policies["prod-k8s-release/*"],
│ provider "provider[\"registry.terraform.io/integrations/github\"]" produced
│ an unexpected new value: Root object was present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

Plan output:

  # module.<repo-name>.github_repository_environment_deployment_policy.environment_deployment_policies["prod-k8s-release/*"] will be created
  + resource "github_repository_environment_deployment_policy" "environment_deployment_policies" {
      + branch_pattern = "release/*"
      + environment    = "prod-k8s"
      + id             = (known after apply)
      + repository     = "<repo-name>"
    }

I checked the GH repo settings and this policy DOES exist currently for that GH environment.

I manually deleted them in the GH environment settings from the screenshot above and reran a TF apply and it was able to successfully "create" them. With them already existing in the GH environment, there is no way that someone would have manually created these. The inclusion of main in there was a recent inclusion in our reusable module so this had been recently applied via TF.

[stevehipwell]

I'll take a look at this, as above I suspect this is a read issue.

[stevehipwell]

I'm going to close this issue with #2993. If anyone sees a similar issue again please check for an existing issue for a single resource type or create a new issue for the type if there isn't already an open issue.