This message was deleted.
# general
s
This message was deleted.
e
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)
d
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 🤔
e
most resources don't need this, and most dep tracking should be handled just fine by pulumi tracking it via Output values
d
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…)
so pulumi knows about the cluster domain and configures it, but when the maintenance task runs, the domain doesn’t resolve just yet
e
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
d
the issue suggests it’s just a latency on the AWS infra side that pulumi has no way of knowing of
i might also make the maintenance job loop and retry for a while if it can’t reach databases it’s supposed to be able to reach
e
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.
d
i would think this is a case for resource options having a possibility to declare the intention
or just accept that this is the kind of hairy business that you just need to deal with in the real world 😎