PostgreSQL K8s charm failed to deploy after removing with `--force --no-wait` (due to K8s service availability)

[taurus-forever]

Steps to reproduce

Juju deploy postgresql-k8s --trust # rev 495 from 14/stable
# wait for deployment, it will be successful 
juju remove-application postgresql-k8s --force --no-prompt --no-wait
# wait for removal

juju secrets # all Juju Secrets have been removed, OK
ID  Name  Owner  Rotation  Revision  Last updated

kubectl get services -n test21047 # a lot of services left, which will block the next deployment
NAME                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
modeloperator                   ClusterIP   10.152.183.222   <none>        17071/TCP           45m
patroni-postgresql-k8s-config   ClusterIP   None             <none>        <none>              4m44s
postgresql-k8s                  ClusterIP   10.152.183.68    <none>        5432/TCP,8008/TCP   5m12s
postgresql-k8s-endpoints        ClusterIP   None             <none>        <none>              5m12s
postgresql-k8s-primary          ClusterIP   10.152.183.44    <none>        8008/TCP,5432/TCP   4m47s
postgresql-k8s-replicas         ClusterIP   10.152.183.30    <none>        8008/TCP,5432/TCP   4m47s

Juju deploy postgresql-k8s --trust # this will stuck

Expected behaviour

The re-deployment should overwrite K8s services and deploy succesfully.
Otherwise block/error charm with message to clean K8s Services garbage.

Actual behaviour

the second Juju deploy postgresql-k8s --trust will stuck if K8s services garbage exist.

Versions

Operating system: 24.04.3 LTS
Juju CLI: 3.6.12
Juju agent: 3.6.12 33252 3/stable canonical✓ -
Charm revision: rev 495 from 14/stable
Canonical K8s: v1.32.10 4531 1.32-classic/edge canonical✓ classic

Log output

No relative logs detected.

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/DPE-8998.

This message was autogenerated

[taurus-forever]

For the history, --no-wait used to be always unstable:

Possible options:

• stop testing wiht --no-wait (as Juju does NOT support this way of removal). We still can bugreport it with minor change to have it fixed.
• improve charm to: a) notice garbage in K8s services and ( b1) error back clearly to the users OR b2) fix/overwrite K8s services)

@dragomirp I think those --no-wait instabilities is your main complain on test_charm stability overall.