Hi, Trying to create flexible server primary and replica. After the primary creation succeeds, the replica creation which references the primary fails, claiming its not in active state. error: 1 error occurred: * resource created but read failed autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The requested resource of type 'Microsoft.DBforPostgreSQL/flexibleServers' with name 'xxxx' was not found.": Code="Failed" Message="The async operation failed." AdditionalInfo=[{"error":{"code":"","message":"Source server 'xxx' is not in active state."},"name":"96d28595-b029-4a41-b37a-5fd17ea48f23","startTime":"2024-06-30T152849.07Z","status":"Failed"}] Retrying after few minutes works. Any idea how to ensure replicas creation are waiting for the primary to become active ?

I'm wondering if there's a way to abuse

.apply

for this - though I'm not sure if .apply can return a promise/future

the actual status needs to be retrieve from the cluster using a rest call until it is in active state.

I've experienced similar things when deploying a new flexible server and f.x. trying to set an Entra admin after creation. This even happens when doing that from the portal – the server is created but not in a fully provisioned state. This seems to be a limitation on the service side.

as the long as the state is exposed in the rest api, its not a limitation. Caller (pulumi) should poll for it.

Since the

pulumi-azure-native

provider is automatically generated from the Azure API schemas the only option for the Pulumi team to implement something like that is by adding manual code to the generated SDK on a per service basis, which increases the likelihood of other types of bugs and will make automatic updates harder (which often automatically fix errors). I've seen them implement those kind of special workarounds for popular resources but I understand their resistance to do so for a SDK with 230+ providers and 9k resources. And if they wanted to implement a standardized way of doing something like that I believe the problem is that there isn't a pattern for those states across services in Azure and criterias for deploying interconnected resources aren't documented in the API schemas. F.x. the Postgres service returns a ServerState string where the value is

Ready

while the Virtual Network api will return a properties.ProvisioningState string with totally different value, namely

Succeeded

Some Azure product teams seem to implement their APIs very well when it comes to catering to the needs of declarative, idempodent IaC deployments while other teams do a poor job and seem to lean on the Portal to guide users, implement custom polling logic or automatic creation/linking/registration of prerequisites during creation. I've learned from hard experience that the Microsoft.DBforPostgreSQL provider is a particularly bad one. The classic and some "hand-written" Terraform providers tend to overcome some of those limitations but instead of getting almost instant SDK updates when new services or functionality is introduced you'll often be dependant on a human contributor to implement fixes, updates and new functionality. So this boils down to being a trade-off... I was frustrated at first when met with these sort of quirks but do value getting immediate SDK access to new functionality over that. However, I've seen some discussions from the Pulumi team around being able to create callbacks with custom logic during resource creation/update lifecycle which could come in handy for those sort of situations. But haven't seen any updates on that for a long time... https://github.com/pulumi/pulumi/issues/1691 https://www.pulumi.com/blog/exploring-circular-dependencies/