knative / knative/eventing

Deletion of subscriptions occurs orphaned subscriber in channel implementaiton's spec

Open
#6,636 8 comments 1 reaction 0 assignees View on GitHub
area/channels kind/bug triage/accepted
Dominant language
Go
Stars
1.6k
Forks
631
Avg merge
2d 1h
Merged PRs (30d)
6

Description

**Describe the bug**

1. Create a channel and some subscriptions that subscribe data from the same channel.
2. Delete the subscriptions
3. The subscriptions are deleted, but the subscription information in the physical channel manifest randomly remains.

https://github.com/knative/eventing/blob/e63b13c341aa6722c5619f32ff4b0fabe661767a/pkg/reconciler/subscription/subscription.go#L439-L470

It seems like:
1. Deletion of several `subscriptions` makes `eventing-controller` handle finalizers for the subscriptions.
2. `eventing-controller` handle finalizers simultaneously.
3. `patchSubscription` use `PATCH` API, so it cannot ensure the resource version.

**Expected behavior**
If a subscription is deleted, an element in `subscriber` in physical channel's spec will be deleted if the uid is the same.

**To Reproduce**

https://gist.github.com/WoWsj/3630deaa315fbc70043449231a4eaa1d

**Knative release version**

v1.8.2

**Additional context**

None

**Questions**

Is there any specific reason to use `Patch`, not `Update`?

I think Using `Update` with `retryOnConflict` is more proper way to ensure the resource versions in this case...

Contributor guide

Open the contributing guide

Research direction

Start with pkg/reconciler/subscription/subscription.go at the referenced lines and inspect patchSubscription. Reproduce the concurrent subscription deletion using the linked gist and trace how the physical channel manifest is updated. Done means deleting subscriptions consistently removes the matching subscriber entry by UID without leaving orphaned subscription information.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend, distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.