Flexible server replica entering in a broken state

[andreidorin-oprea]

Describe the bug

We are creating some postgres instances with geo replica. Creation works as expected, everything enters ready state. At some point there is a pod restart and everything is again reconciled. The objects defining the replica enter in a continuous transition state between Reconciling and ReadReplicaAlreadyExistWithGivenName, with the error Cannot create read replica '<name>' because a server with that name already exists

Azure Service Operator Version: 2.17.0

Expected behavior

The controller should pick up that there is an existing replica and adopt it.

To Reproduce

1. Apply object for primary

apiVersion: dbforpostgresql.azure.com/v20250801
kind: FlexibleServer
metadata:
  name: tst-df-postgres2
spec:
  administratorLogin: postgreSQLAdmin
  administratorLoginPassword:
    key: password
    name: tst-df-postgres2
  authConfig:
    activeDirectoryAuth: Enabled
    passwordAuth: Enabled
  azureName: tst-df-postgres2
  location: northeurope
  owner:
    armId: <rg_arm_id>
  sku:
    name: Standard_D2ds_v5
    tier: GeneralPurpose
  storage:
    storageSizeGB: 64
  version: "16"

2. Apply object for secondary

apiVersion: dbforpostgresql.azure.com/v20250801
kind: FlexibleServer
metadata:
  name: tst-df-postgres2-secondary
spec:
  azureName: tst-df-postgres2-secondary
  createMode: Replica
  highAvailability:
    mode: ZoneRedundant
  location: westeurope
  owner:
    armId: <rg_arm_id>
  sourceServerResourceReference:
    group: dbforpostgresql.azure.com
    kind: FlexibleServer
    name: tst-df-postgres2

3. Restart controller

Screenshots

[matthchr]

Just confirming, the primary is fine and doesn't have any of these issues, it's just the read replica that has the problem?

This looks like a bug to me. ASO expects that the underlying API is idempotent, but it looks like maybe this read replica API isn't? I'll do some testing and if we can confirm that the underlying API isn't idempotent I will reach out to the PostgreSQL team for recommendations.

[theunrepentantgeek]

The createMode for flexibleServer has some interesting options:

• Create
• Default
• GeoRestore
• PointInTimeRestore
• Replica
• ReviveDropped
• Update

Having Update in that list seems provocative - I wonder if we need to implement the ARMResourceModifier extension to detect whether the replica already exists and to switch the createMode if it does. We already do something a little like this for KeyVaults.

[andreidorin-oprea]

Just confirming, the primary is fine and doesn't have any of these issues, it's just the read replica that has the problem?

Yup, the object for primary is fine