gcp.projects.Service doesnt block on the service actually being enabled so the dependent resources fail with "If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry." - even when you use dependsOn

If we don't have an issue for this on the repository please create one, either on this or the google-native repository! If I recall correctly, GCP doesn't provide any API for us to query or poll on to check if the enablement has succeeded.

Thanks friel, https://github.com/pulumi/pulumi/issues/12163 I ended up with

const firestoreService = new local.Command(`firestore-service`, {
  create: `gcloud services enable <http://firestore.googleapis.com|firestore.googleapis.com>`,
  delete: `gcloud services disable <http://firestore.googleapis.com|firestore.googleapis.com> `,
});

The rest of firestore seems quite messy. GCP Classic doesn't create a db so have to use GCP Native. Cant destroy on a Document resource. I prob just need to use the local.Command for the rest of it too since Im already depending on gcloud.

For what it's worth,

gcloud services enable

has the same caveat, it exits with success but APIs may still error for a usually brief period of time following.

I continuously polled on the service availability as I gcloud services enable and the cmd did not return success until the service was enabled. Confirmed on disabling the service as well and the cli has an --async flag that I think we use when we do not want to block. I also did not experience the race in my pulumi plan. Friendly general guidance or do you know for sure that

gcloud services enable

does not block until the service is available?

Friendly guidance, though informed by experience. Before I joined Pulumi last year, I was a Pulumi & GCP user for a few years and I saw races between

gcloud services enable ... && pulumi up

. If they have a blocking API now and we're not using it, that'd be a good improvement to this resource. Thanks for filing an issue on pulumi-gcp

@orange-policeman-59119 thanks for looking at this. it was the firestore service. I did scrap setting this up in pulumi over the race and over the situation with the firestore resources not handling the non-destroy-able constraint.