google_sql_user fails with Root was present, but now absent if host value is set and cloudsql instance is Postgres

[chasinglogic]

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 the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.1.6
on darwin_arm64

Affected Resource(s)

• google_sql_user

Terraform Configuration Files

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.13.0"
    }
  }
}

resource "google_sql_database_instance" "main" {
  name             = "issue-example"
  database_version = "POSTGRES_13"
  region           = "europe-west2"
  project          = "example-project"

  settings {
    tier = "db-f1-micro"
  }
}

resource "google_sql_user" "example_user" {
  instance = google_sql_database_instance.main.name
  project  = "example-project"

  name     = "example_user"
  password = "example-pass"
  host     = "%"
}

Debug Output

https://gist.github.com/chasinglogic/10ccfc765fd32096067fa6e598c3dd40

Expected Behavior

Any one of the following behaviours would be acceptable IMO:

• Reject the invalid config value with a better error message
• Silently ignore the host config and provision the user

This was a hard to debug issue since there wasn't any obvious information about why it was happening.

Actual Behavior

Terraform produces the "Root resource was present, but now absent" error message. Indicating it might be a bug in the provder.

google_sql_user.example_user: Creating...
google_sql_user.example_user: Still creating... [10s elapsed]
google_sql_user.example_user: Still creating... [20s elapsed]
╷
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to google_sql_user.example_user, provider "provider[\"registry.terraform.io/hashicorp/google\"]" produced an
│ unexpected new value: Root resource was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Steps to Reproduce

1. terraform apply the given example terraform

Important Factoids

None, this was reproduced on a fresh GCP project and instance from scratch using the given example Terraform.

I'd be happy to implement the chosen solution but feel it's important to understand whether the silent acceptance or rejection would be the preferred solution first.

[Kundan22]

#11488#issuecomment-1099792809 - Adding a delay before creating SQL User worked for me as it allows time to get DB prepared and come online.

[chasinglogic]

The bug here is that if you don't specify host = at all then you don't need a wait or any other hack it just works.

[dmead]

this is still an issue. I've noticed that on my machine with the latest provider i'm still sending host to the server.

it's not set in terraform and the docs say to not set this for postgres. Should this be sending host: ""?

 {
   "kind": "sql#user",
   "etag": "<redacted>",
   "name": "<redacted>",
   "host": "",
   "instance": "<redacted",
   "project": "<redacted>",
   "type": "CLOUD_IAM_USER"
  }

and then in terraform

resource "google_sql_user" "staff" {
provider = <the correct provider>
project  =  <the correct project id>
name     = <redacted email address>
instance = <redacted google_sql_database_instance>
type     = "CLOUD_IAM_USER"
}

it should be noted that my google_sql_database_instance is postgres and I'm able to establish types of CLOUD_IAM_SERVICE_ACCOUNT just fine.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.