Extend possible responses for create subscription request with 202

[shilpa-padgaonkar]

Currently, the subscription spec documents 2 responses:

• 201 Created successfully
• 400 Invalid request

The subscription create request allows a consumer to subscribe to multiple event types. As there are multiple event types requested, could there be a possibility (to avoid timeout possibilities) to respond with 202 indicating that the subscription create request has been accepted for processing but has not been finished yet?

[duglin]

@shilpa-padgaonkar in general that seems reasonable, however, I'm curious how you see that working? For example, would it return a 202 + a Location header where the subscription resource will eventually appear? Basically, how does the client know when the subscription is ready and how would they get the Subscription resource itself? There are options.... I'm just curious as to which you think is most appropriate.

[shilpa-padgaonkar]

@duglin IMHO there is a need for subscription lifecycle management.

In addition to the domain specific events that could be subscribed to, using the subscriptions API, there could be default events to notify about the subscription's state.
Currently, I am just dealing with webhooks. In this case, the (event) consumer could get notified after the initial response of 201 (subscription requested) with the below listed (example) notifications whenever there is an update in the subscription's status at the same sink (notification URL) which is a part of the subscription create request.

• example.common.subscription.active
• example.common.subscription.terminated

I am dealing with events which might need to get end user consent. In such cases, if the end user refuses to grant consent, the event consumer can be notified that the subscription was terminated or if the end user grants consent, the event consumer gets notified that the subscription is now active.

Not sure though if this requirement is very specific, or do you see this as something that might be useful in general?

[github-actions]

This issue is stale because it has been open for 30 days with no
activity. Mark as fresh by updating e.g., adding the comment /remove-lifecycle stale.