google_bigtable_schema_bundle creation always results in tainted resource

[kasai-shuntaro]

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 & Provider Version(s)

Terraform v1.9.0
on darwin_arm64

• provider registry.terraform.io/hashicorp/google v7.11.0

Affected Resource(s)

google_bigtable_schema_bundle

Terraform Configuration

resource "google_bigtable_table" "example" {
    name          = "example_table"
    instance_name = google_bigtable_instance.example.name

    column_family {
      family = "ExampleFamily"
    }

    change_stream_retention = "0"
  }

  resource "google_bigtable_gc_policy" "example" {
    instance_name   = google_bigtable_instance.example.name
    table           = google_bigtable_table.example.name
    column_family   = "ExampleFamily"
    deletion_policy = "ABANDON"
    gc_rules        = jsonencode({"rules": [{"max_age": "1s"}]})
  }

  resource "google_bigtable_schema_bundle" "example" {
    instance         = google_bigtable_instance.example.name
    table            = google_bigtable_table.example.name
    schema_bundle_id = "example_bundle"

    proto_schema {
      proto_descriptors = filebase64("${path.module}/example.pb")
    }

    ignore_warnings = true

    depends_on = [
      google_bigtable_table.example,
      google_bigtable_gc_policy.example,
    ]
  }

Debug Output

no

Expected Behavior

When creating a new Bigtable table with a schema bundle in a single terraform apply:

1. Table should be created
2. GC policy should be created
3. Schema bundle should be created successfully
4. Resource should not be tainted

Actual Behavior

The schema bundle resource is created successfully in GCP, but Terraform marks it as tainted due to an error
during the post-creation read operation:

Error: Error when reading or editing BigtableSchemaBundle
"projects/PROJECT/instances/INSTANCE/tables/TABLE/schemaBundles/BUNDLE_ID":
googleapi: Error 400: Parent table projects/PROJECT/instances/INSTANCE/tables/TABLE is either creating or
deleting, please try again.

The schema bundle is actually created successfully in GCP (verified with gcloud bigtable schema-bundles
describe), but Terraform considers the resource creation failed because the immediate Read call after creation
fails.

Steps to reproduce

1. Create a fresh Terraform configuration with table, GC policy, and schema bundle resources
2. Run terraform apply
3. Observe that:
   - Table creation completes in ~2 seconds
   - GC policy creation completes in ~1 second
   - Schema bundle POST request succeeds
   - Schema bundle GET request (read) fails with "table is creating or deleting" error
   - Resource is marked as tainted

Important Factoids

• This issue occurs 100% of the time when creating a table and schema bundle together in a single apply
• The schema bundle is successfully created in GCP despite the Terraform error
• Even after the initial creation, running terraform apply again produces the same error:
  • The resource remains tainted, causing persistent plan drift
  • Running terraform untaint google_bigtable_schema_bundle.RESOURCE_NAME removes the taint and eliminates
    the drift
  • After untainting, terraform plan shows no changes, confirming the resource exists correctly
• The API explicitly suggests a 30-second retry delay in the error response via RetryInfo
• No retry logic exists in the current provider implementation for this specific error
• Wait time before schema bundle creation does not solve the issue:
  • Tested with 10s, 60s, and 180s delays - all failed
  • The error occurs during the Read operation immediately after the successful POST request, not before
    creation

References

No response