This message was deleted.

I thought we had some guides around this but I'm struggling to find anything now. The normal trick is to do an

apply

and put a wait inside the apply (using something like Thread.Sleep, or whatever is supported in your language) and pass that new output value to the

dependsOn

list of the resource. Some resources have a

Ready

property which is just a fancier version of the above (it doesn't sleep but actually checks the resource is ready)

i should probably declare explicit dependencies on the other resources just in case those resources actually do wait until they’re fully done, they just become partially done and allow filling in configuration values before that 🤔

most resources don't need this, and most dep tracking should be handled just fine by pulumi tracking it via Output values

yes, most of the time it’s not a problem at all, but i do sometimes seem to hit edge cases with the weird stuff i’m doing (specifically: AWS secrets manager triggers an event when updated, which spawns an ECS task to run application maintenance jobs e.g. to migrate databases, which in this case runs before the new database cluster has fully provisioned…)

yeh domain stuff is often slow, doing a loop inside an apply to make the next resource not trigger till the domain resolves would be a good fix

the issue suggests it’s just a latency on the AWS infra side that pulumi has no way of knowing of

Pretty much, AWS returns quickly when we tell them to create the domain and we currently just use the create method returning a result as evidence that the resource is created. But there are some cases where created != ready. We could probably do better here, but it would be a manual fix up per-resource, and we don't want to slow Creates down (because sometimes you are just creating the thing, not using it in the same deployment), so not totally clear what would be best here.

i would think this is a case for resource options having a possibility to declare the intention