google_cloudfunctions2_function is not updated when the object it depends on is replaced

[Hyaxia]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to a user, that user is claiming responsibility for the issue.
• Customers working with a Google Technical Account Manager or Customer Engineer can ask them to reach out internally to expedite investigation and resolution of this issue.

Terraform Version

5.17.0

Affected Resource(s)

google_cloudfunctions2_function

Terraform Configuration

Debug Output

No response

Expected Behavior

google_cloudfunctions2_function is not updated when the object it depends on is replaced. meaning that for the following configuration:

build_config {
    runtime = "nodejs16"
    entry_point = "helloHttp"  # Set the entry point 
    source {
      storage_source {
        bucket = google_storage_bucket.bucket.name
        object = google_storage_bucket_object.object.name
      }
    }
  }

if google_storage_bucket_object.object. is replaced, then the functions should be replaced aswell.

Actual Behavior

There is a difference between version 5.11.0 and current version (5.17.0). If an object that google_cloudfunctions2_function is dependant on is replaced, then in version 5.11.0 the functions are replaced aswell. But its not the case in 5.17.0, only the object is replaced, without any updates to the cloud function.

Steps to reproduce

1. terraform apply

Important Factoids

No response

References

No response

[c2thorn]

Do you have the output of a plan where Terraform is going to update after the object is replaced (in 5.11)?

I suspect that the update was caused by a different field. If the object name isn't changing after replacement, then Terraform may detect a change. We may have to add a hash field to detect when the contents of the object change instead of the name.

Alternatively, if you are okay with the function fully recreating, you could use https://developer.hashicorp.com/terraform/language/meta-arguments/lifecycle#replace_triggered_by now.

[TulyOpt]

Hello,

any news on this ? I have the same problem. And recreating the function is not a good solution for us.

[ggtisc]

I tried to reproduce this scenario with the next code based on this example:

locals {
  project = "my-project-name" # Google Cloud Platform Project ID
}

resource "google_storage_bucket" "sb_17347" {
  name     = "sb-17347"
  location = "US"
  uniform_bucket_level_access = true
}

resource "google_storage_bucket_object" "sbo_17347" {
  name   = "index17347.zip"
  bucket = google_storage_bucket.sb_17347.name
  source = "./utils/index.zip"
}

resource "google_cloudfunctions2_function" "cf2_func_17347" {
  name = "cf2-func-17347"
  location = "us-central1"
  description = "something"

  build_config {
    runtime = "nodejs16"
    entry_point = "helloGET"
    source {
      storage_source {
        bucket = google_storage_bucket.sb_17347.name
        object = google_storage_bucket_object.sbo_17347.name
      }
    }
  }

  service_config {
    max_instance_count  = 1
    available_memory    = "256M"
    timeout_seconds     = 60
  }
}

Then after creating the resources with a 1st terraform apply I changed the code of the google_storage_bucket_object.sbo_17347 like this:

resource "google_storage_bucket_object" "sbo_17347" {
  name   = "index17347.zip"
  bucket = google_storage_bucket.sb_17347.name
  source = "./utils/index2.zip"                                                               #change here!
}

But after changing the google_storage_bucket_object.source the result was normal replacing the existing google_storage_bucket_object and applying an update-in-place for the google_cloudfunctions2_function.

If you still continue with issues share your own configuration to replicate this again and see what is happening.