❗ By default, the pull request is configured to backport to all release branches.

• To stop backporting this pr, remove the label: backport-requested ◀️ or add the label 'do not backport'
• To stop backporting this pr to a certain release branch, remove the specific branch label: release-x.y

Hello @simonapencea, crediting you as co-author for your initial analysis, feel free to add suggestions or feedbacks and so on to the patch!

/test

@armru, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22760727137

This is very close to what I had in mind as well — thanks for taking this on!

One thing that might still be worth noting is that the check and the creation of the replica are not a single atomic operation. Because of that, there is technically a small window where the volume could exist when the check happens but be deleted before it is actually used as the data source.

That said, this change strengthens the behavior quite a bit and should cover the vast majority of cases. It also makes recovery from that edge case much easier if it ever happens.
Right now, recovering from that situation can be fairly involved, whereas with this change I would expect that deleting the pending PVC together with the snapshot-recovery job should allow the next reconciliation loop to create the correct type of job again.

Overall this looks like a solid improvement to me 👍

Hello @simonapencea! I want to make sure I'm not missing something. Are you referring to:

• The time window between the snapshot existence check and the actual PVC creation within the same reconciliation loop? Would you suggest a different approach to address this? CNPG in general (not just the snapshots pkg) follows the eventual consistency pattern, like many Kubernetes operators where multiple components interact and report state concurrently. That said, if we want to handle recovery for the case where a snapshot is deleted during that narrow execution window, I'm personally open to an eventual contribution on that matter (would love to hear other maintainers opinion on this) but I think it belongs in a separate PR as an incremental improvement.

• Or some other behavior I might be overlooking? If so, I'd appreciate the additional context so we can evaluate whether it warrants a change.

I've added a commit that handles the case where a VolumeSnapshot is deleted between the operator's existence check and the PVC creation, leaving the PVC stuck in Pending and the restore Job blocked indefinitely. The new code detects these orphaned PVCs and cleans them up along with their associated Jobs, allowing the operator to retry via pg_basebackup on the next reconciliation. I'll let the other maintainers decide whether this warrants a separate PR or can be merged with this one.

/test

@armru, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22770102467

Sorry i missed this, yes, that was exactly the case i was referring to.

As to including it here or in a separate PR, i have no opinion.

The PR was super valuable even without considering this edge case.
So i am happy either way :)

Hi! Following a discussion with @armru, we've decided to move the second commit into a separate PR (#10223). This will allow us to discuss and review each change independently.

/test

@leonardoce, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22850513034

I approve this, but the current process lacks transparency and control. In the long term, we need to address #9176 to provide clarity to users.