What happens when you have 10 subscription and one is not ready?

[n3wscott]

https://github.com/knative/eventing/pull/482/files#r226776116

[evankanderson]

The 9 that are ready should be sent to by the Channel, and the 10th might or might not be (undefined for the 10th, IMO).

[scothis]

There are multiple forms of "not ready", and it will also depend on the implementation details of the channel. Errors and misconfigurations are very common and should not break normal communication flows.

If the subscription is unable to be resolved or provisioned, then it effectively doesn't exist. If the subscription was previously provisioned then it should be deprovisioned after being in an error state for some period of time. The other 9 subscriptions operate normally.

If the subscription is provisioned, but unable to deliver events, then the channel must have the choice to either drop the event or requeue for future delivery. The event should permanently fail after some number of attempts or duration. That choice and needs to be clear and documented. The other 9 subscriptions operate normally.

If the channel performs fanout itself (like the in-memory channel), it may decide to drop the event for the erring subscription, retry only the erring subscription, or retry the event for all subscriptions. This choice must be clearly documented. Subscribers are responsible for guarding against duplicate delivery.

[evankanderson]

In this case, I think we're specifically talking about the Ready condition on the Subscription, which I think would indicate that the following had taken place:

1. The call and result ObjectReferences had been resolved to URLs.
2. The URLs from the first item had been written to the spec.subscribers.{callableUrl,sinkableUrl}

[markfisher]

The behavior would still depend on the Channel implementation. For example, with Kafka-backed Channels it should be possible to specify the offset auto reset behavior (when no explicit commit offset is yet known) to be either "earliest" or "latest". In the latter case, the actual offset would correspond to the first event available upon the consumer group being established, but in the former case, it would enable reading all events currently available on that topic (which depends upon the retention policy... e.g. could be "7 days").

[akashrv]

Each subscription status is part of channel's status.
/close

[knative-prow-robot]

@akashrv: Closing this issue.

Details

In response to this:

Each subscription status is part of channel's status.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.