bug: SyncAgent ignores Finalizer on deletion

[BergCyrill]

Describe the bug

As soon as a resource in a kcp workspace is requested to be deleted the api-syncagent will proceed to delete the corresponding resource in the service provider cluster. This does even happen if there are (other) finalizers set on the resource in kcp which should prevent this deletion behavior.

Related lines:

api-syncagent/internal/sync/object_syncer.go

Lines 94 to 98 in 6b75d0a

	func (s *objectSyncer) Sync(ctx context.Context, log *zap.SugaredLogger, source, dest syncSide) (requeue bool, err error) {
	// handle deletion: if source object is in deletion, delete the destination object (the clone)
	if source.object.GetDeletionTimestamp() != nil {
	return s.handleDeletion(ctx, log, source, dest)
	}

Steps To Reproduce

1. Create a resource for a synced API
2. Add a custom finalizer "foo/bar"
3. Request this resource to be deleted
4. Watch API-SyncAgent to delete the resource in the service provider cluster

Expected Behaviour

I would expect the api-syncagent to respect finalizers and only delete a synced resource in the service provider cluster if there are no more finalizers (except for the own one) set on the resource in kcp.

Additional Context

No response

[xrstf]

Hi,

This does even happen if there are (other) finalizers set on the resource in kcp which should prevent this deletion behavior.

I don't think this is a workable interpretation of finalizers. What if you have 2 operators both waiting for all but their own finalizers to be gone? Especially if we were, for example, change the finalizers to be per-agent (#117), then we would quickly run into a deadlock.

If we implemented this, if a customer had automation in place that does the same, then we would even block that automation from ever completing. In this situation, the user would have to intervene and remove our finalizer, so their own scripting can continue cleaning up, which in turn breaks our own cleanup logic.

What I could imagine is allowing the agent to not wait for the copy of the object to be gone. So it just issues a delete / ensures a deletionTimestamp is set, but considers this enough to release the finalizer on the source object. Then you can have an additional finalizer on the destination (probably provider) side that keeps the object around for longer, if you want to delay cleanup on the provider side.