Zalando operator switch postgresqls.acid.zalan.do state to Running while no one replica successfully started

• Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.10.0
• **Where do you run it - cloud or metal? ### Kubernetes
• Are you running Postgres Operator in production? no
• Type of issue? Bug report

I've found some interesting behaviour with zalando-operator,

1. When postgresqls.acid.zalan.do created with resource request (cpu/ram) or Node affinity with big/inappropriate values --> the goal is that Kubernetes Scheduler can not deploy no one replica and even first must get stuck Pending state ).
2. So, then as we expect 1st replica get stuck in Pending bc of e.g. insufficient cpu in resource request.
3. Thus during the cluster creation that https://github.com/zalando/postgres-operator/blob/af084a5a650527c43f0c0fc579551a741e77f5c8/pkg/cluster/cluster.go#L328 validation will fail and postgresqls.acid.zalan.do CR is switched to CreateFailed state.
4. However, after some time zalando-operator switch database to Running (after or during sync) state. So, there will be still 1 Pod getting stuck in Pending however status of whole postgresqls.acid.zalan.do instance will be Running.

Its actually confusing. Unfortunately I didn't find the reason in zalando-operator code and here is the question:

Was this implemented intentionally for some reasons or is this incorrect behaviour? Since I don't really understand why the zalando-operator marks it as Running state, when in fact no one replica has even started and Create method has not completed successfully.

Start in pkg/cluster/cluster.go at the Create method around line 244 and the validation around line 328. Reproduce a cluster with resource requests or node affinity that leaves its first replica Pending, then trace the sync behavior that changes the CR state. Done means the observed state transition is explained and the status accurately reflects whether a replica started.