bug: finalizer "syncagent.kcp.io/cleanup" on related resources block deletion of primary object

Open

#172 opened on Jun 23, 2026 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 4/5
Estimated time: 3-5 days
Newbie friendliness: 48/100

Issue type: Bug
Clarity: Mostly clear
Activity status: Quiet
Tech stack: go
Domain: backend, distributed-systems

Research direction

Start by reproducing the provider A/B setup with the Network and VirtualMachine manifests in this issue, then trace finalizer cleanup for primary and related resources. Review issues #116 and #117 for context; done means deleting the VirtualMachine no longer leaves the Network blocked by a finalizer that is immediately re-added.

Written by the indexing model from the issue text.

Description

kind/bug

Describe the bug

Let's assume, there are two service providers using the api-syncagent to publish API resources and sync objects to / from kcp. To have a concrete example, let's also assume that:

service provider "A" provides a Network API
service provider "B" provides a VirtualMachine API that allows you to reference an existing Network (defined as related resource) in which the virtual machine should be created

In this case, both api-syncagents add the finalizer "syncagent.kcp.io/cleanup" to any Network object referenced by a VirtualMachine - the api-syncagent of service provider "A" since the Network is the primary object, the api-syncagent of service provider "B" since the Network object is a related resource with origin: kcp.

When a VirtualMachine is deleted, provider "B" removes the finalizer from the Network as part of cleanup — but provider "A" immediately re-adds it, blocking deletion indefinitely.

Steps To Reproduce

service provider "A": install api-syncagent and created PublishedResource for Network

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: networks.network.example.com
spec:
  group: network.example.com
  names:
    kind: Network
    listKind: NetworkList
    plural: networks
    singular: network
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              cidrBlock:
                type: string
    served: true
    storage: true
---
apiVersion: syncagent.kcp.io/v1alpha1
kind: PublishedResource
metadata:
  name: networks.network.example.com
spec:
  resource:
    apiGroup: network.example.com
    versions: [v1]
    kind: Network
  naming:
    namespace: 'ws-{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}'
    name: '{{ .Object.metadata.name }}'

service provider "B": install api-syncagent and created PublishedResource for VirtualMachine

---
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: virtualmachines.compute.example.com
spec:
  group: compute.example.com
  names:
    kind: VirtualMachine
    listKind: VirtualMachineList
    plural: virtualmachines
    singular: virtualmachine
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              networkRef:
                type: object
                properties:
                  name:
                    type: string
    served: true
    storage: true
---
apiVersion: syncagent.kcp.io/v1alpha1
kind: PublishedResource
metadata:
  name: virtualmachines.compute.example.com
spec:
  resource:
    apiGroup: compute.example.com
    versions: [v1]
    kind: VirtualMachine
  naming:
    namespace: 'ws-{{ .ClusterName }}-{{ .Object.metadata.namespace | sha3short }}'
    name: '{{ .Object.metadata.name }}'
  related:
    - identifier: network
      origin: kcp
      group: network.example.com
      version: v1
      resource: networks
      identityHash: ${NETWORKS_API_EXPORT_IDENTITY_HASH}
      object:
        reference:
          path: spec.networkRef.name

consumer: bind both APIExports, apply manifests, and delete VirtualMachine

---
apiVersion: network.example.com/v1
kind: Network
metadata:
  name: network
spec:
  cidrBlock: "192.168.0.0/24"
---
apiVersion: compute.example.com/v1
kind: VirtualMachine
metadata:
  name: vm
spec:
  networkRef:
    name: network

Expected Behaviour

The VirtualMachine should get deleted successfully

Additional Context

Dominant language: Go
Stars: 25
Forks: 30
Avg merge: 3d 9h
Merged PRs (30d): 2

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

nix: vendorHash is outdated Open

Difficulty 1/5 Under an hour Newbie friendliness 90/100

abenz1267/elephant#301 · 1 reaction · Opened Sep 24, 2026
Bob Shell support Open

enhancement

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

rossoctl/cortex#1119 · Opened Sep 24, 2026
[BUG] CREATE property value with *, -, ^, % or unary minus is stored as its text ('2 * 3'); + and / are evaluated Open

bug

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

orneryd/NornicDB#656 · Opened Sep 24, 2026
HaveExactElements' failure message omits where the missing or extra elements start when that index is 0 Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

onsi/gomega#934 · Opened Sep 24, 2026
propertyNames and contentSchema errors: InstanceLocation is overwritten by later siblings Open

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

santhosh-tekuri/jsonschema#276 · Opened Sep 24, 2026

More Go issues