google_firestore_document.document: GoogleApi Error 400: Missing routing header #15550

ch3ck · 2023-08-17T20:57:48Z

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.5.0
on linux_amd64

Your version of Terraform is out of date! The latest version
is 1.5.5. You can update by downloading from https://www.terraform.io/downloads.html

Affected Resource(s)

google_firestore_document

Terraform Configuration Files

resource "google_firestore_document" "documents" {
  for_each = { for doc in var.collections : doc.document => doc }

  provider    = google-beta
  project     = local.project_id
  database    = var.database_name
  collection  = each.value.collection
  document_id = each.value.document
  fields      = jsonencode(each.value.fields)

  depends_on = [
    google_firestore_database.firestore
  ]
}

Debug Output

Panic Output

See error below

Expected Behavior

No error

Actual Behavior

google_firestore_document.documents["fake-test-user"]: Creating...
╷
│ Error: Error creating Document: googleapi: Error 400: Missing routing header. Please fill in the request header with format x-goog-request-params:project_id=XXXXXXX. Please refer to https://firebase.google.com/docs/firestore/manage-databases#access_a_named_database_with_a_client_library for more details.
...

Steps to Reproduce

terraform apply

Important Factoids

Terraform provider:

terraform {
  required_providers {
    google = {
      source = "hashicorp/google"
      version = "4.78.0"
    }
  }
}

provider "google" {
  # Configuration options
}

References

The text was updated successfully, but these errors were encountered:

edwardmedia · 2023-08-17T22:10:58Z

b/296467504

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The basic Field example is also creating its own project and its own database now for test isolation purposes. It might be sufficient to just create a database the same way as for backup schedules; we can evaluate that once the tests have been passing for a while. * The other two Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do.

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do.

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do. [upstream:003fa68204d7bcff11e5153364e8c6eb950155ed] Signed-off-by: Modular Magician <[email protected]>

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do. [upstream:003fa68204d7bcff11e5153364e8c6eb950155ed] Signed-off-by: Modular Magician <[email protected]>

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do. [upstream:003fa68204d7bcff11e5153364e8c6eb950155ed] Signed-off-by: Modular Magician <[email protected]>

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do. [upstream:003fa68204d7bcff11e5153364e8c6eb950155ed] Signed-off-by: Modular Magician <[email protected]>

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do.

narendraaduri1 · 2024-01-25T10:16:07Z

please look at this issue Error: Error creating Document: googleapi: Error 400: Missing routing header. Please fill in the request header with format x-goog-request-params:project_id=xxxxxxxx&database_id=firestoredatabase02. Please refer to https://firebase.google.com/docs/firestore/manage-databases#access_a_named_database_with_a_client_library for more details.

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do.

nguyen-vo · 2024-03-18T17:15:18Z

hi, will this issue be fixed soon and are there any workaround in the mean time

melinath · 2024-04-09T22:30:12Z

This should now be resolved.

ch3ck · 2024-04-10T10:38:01Z

@melinath which provider version has this fix?

melinath · 2024-04-10T15:58:18Z

The API no longer requires the routing header, so it should work in all provider versions that support this resource. Definitely let us know if that doesn't seem to be the case!

There's a whole bunch of different constraints that have to be met for these tests to pass consistently. * Backup schedules need to be run in a project with billing enabled, and the database needs a deletion policy to ensure it is properly swept. * The default-database examples were marked as skip-test. They're valuable as examples but not really as tests - there's nothing Terraform-specific about them worth testing - and the Field tests will fail if default database creation doesn't work in Terraform * The Document tests need to run against the (default) database due to an existing bug (hashicorp/terraform-provider-google#15550). So they will now create their own project and their own (default) database. * The Field examples are following the same pattern as the backup schedule examples. * The Firestore-native index example is using the inband project creation method, because then we can use the (default) database, which means we can use the Document resource (see the above-mentioned bug), which means that we don't need to use a manually-created project (because creating a Document implicitly creates its collection). * The Datastore mode Index example can't take that same approach, because it doesn't seem like the Document resource works on datastore-mode databases. So we will need to use the manually-created FIRESTORE_PROJECT_NAME project for that one, and it will need to have a Datastore mode database manually baked into it. This exercise has identified a fair number of places for improvement to the Firestore Terraform story, but as a stopgap to get the tests passing again, this will have to do.

github-actions · 2024-05-11T02:02:25Z

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.

ch3ck added the bug label Aug 17, 2023

github-actions bot added forward/review In review; remove label to forward service/firestore-dataplane labels Aug 17, 2023

edwardmedia added forward/linked and removed forward/review In review; remove label to forward labels Aug 17, 2023

ansgarm mentioned this issue Sep 6, 2023

firestore-document: Error creating Document: googleapi: Error 400: Missing routing header hashicorp/terraform-cdk#3117

Closed

1 task

This was referenced Oct 23, 2023

Clarify the database resource name in firestore document surface GoogleCloudPlatform/magic-modules#9325

Merged

Support configurable HTTP header in magic module #16331

Closed

This was referenced Oct 23, 2023

Clarify the database resource name in firestore document surface #16338

Merged

Clarify the database resource name in firestore document surface hashicorp/terraform-provider-google-beta#6558

Merged

rwhogg mentioned this issue Jan 18, 2024

Firestore: Fix tests GoogleCloudPlatform/magic-modules#9840

Merged

This was referenced Jan 22, 2024

Firestore: Fix tests #17070

Merged

Firestore: Fix tests hashicorp/terraform-provider-google-beta#6885

Merged

modular-magician mentioned this issue Jan 22, 2024

Firestore: Fix tests GoogleCloudPlatform/terraform-google-conversion#1887

Merged

pl04351820 mentioned this issue Apr 2, 2024

Remove database resource name constraint in firestore document surface GoogleCloudPlatform/magic-modules#10346

Merged

This was referenced Apr 3, 2024

Remove database resource name constraint in firestore document surface hashicorp/terraform-provider-google-beta#7187

Merged

Remove database resource name constraint in firestore document surface #17765

Merged

melinath closed this as completed Apr 9, 2024

melinath mentioned this issue Apr 9, 2024

Allowed modifying request headers via pre_create, pre_read, pre_update, or pre_delete custom code GoogleCloudPlatform/magic-modules#10405

Merged

github-actions bot locked as resolved and limited conversation to collaborators May 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

google_firestore_document.document: GoogleApi Error 400: Missing routing header #15550

google_firestore_document.document: GoogleApi Error 400: Missing routing header #15550

ch3ck commented Aug 17, 2023 •

edited by rileykarson

Loading

edwardmedia commented Aug 17, 2023

narendraaduri1 commented Jan 25, 2024

nguyen-vo commented Mar 18, 2024

melinath commented Apr 9, 2024

ch3ck commented Apr 10, 2024

melinath commented Apr 10, 2024

github-actions bot commented May 11, 2024

google_firestore_document.document: GoogleApi Error 400: Missing routing header #15550

google_firestore_document.document: GoogleApi Error 400: Missing routing header #15550

Comments

ch3ck commented Aug 17, 2023 • edited by rileykarson Loading

Community Note

Terraform Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

edwardmedia commented Aug 17, 2023

narendraaduri1 commented Jan 25, 2024

nguyen-vo commented Mar 18, 2024

melinath commented Apr 9, 2024

ch3ck commented Apr 10, 2024

melinath commented Apr 10, 2024

github-actions bot commented May 11, 2024

ch3ck commented Aug 17, 2023 •

edited by rileykarson

Loading