How to inform API consumer about unprocessable subscription request in Async mode

[bigludo7]

Problem description
In our subscription model we offer possibility for server to handle it synchronously or asynchronously.

Suppose we have a subscription request that the server is not able to handle (the monitoring area is not within operator area, the reachability status could ne follow this specific number, etc...) and the subscription server handles it in async mode.

How to inform the subscription requester that the request in not processable when server manages it in asynchronously ?

(in sync mode we do not have issue as we send back a 4xx error)

Possible evolution

• add another TerminationReason value: SUBSCRIPTION_UNPROCESSABLE
• add terminationReasonComment attibute to allow server to provide explantation

Alternative solution

Additional context
cc: @PedroDiez & @shilpa-padgaonkar @akoshunyadi

[PedroDiez]

I understand this would be the case where, being a Telco Operator behaving in async mode, the processing of the subscriptionDetail information is happening after providing a subcriptionId.

So as, if GET /subscription would be queried, the "status" of the subscriptionId would be "ACTIVATION_REQUESTED" and after the processing is done and realized cannot be managed, the new proposed eventTermination Reason is returned back: SUBSCRIPTION_UNPROCESSABLE.

Regarding the final "status" of this kind of subscriptions, I think the best approach is not kept as "DELETED" and effectively removed them "as they never existed" because it adds no historical value a subscription that would never be working (just thinking in loud).

In principle makes sense to me and I am checking in parallel internally with our team

[maxl2287]

@PedroDiez did you already have time to check this internally with your team?

[rartych]

It occurred that we have optional property in event-subscription-template.yaml :

Commonalities/artifacts/camara-cloudevents/event-subscription-template.yaml

Lines 629 to 630 in 9233f83

	terminationDescription:
	type: string

Currently it is not used in subscription APIs and missing description attribute.

[maxl2287]

@rartych From DeviceLocation side we aggree on using the terminationDescription. ✅
The second proposal from @bigludo7 was to add the terminationReason SUBSCRIPTION_UNPROCESSABLE.

Can we also align on that?

cc @PedroDiez @shilpa-padgaonkar @jlurien

[maxl2287]

@rartych From DeviceLocation side we aggree on using the terminationDescription. ✅ The second proposal from @bigludo7 was to add the terminationReason SUBSCRIPTION_UNPROCESSABLE.

Can we also align on that?

cc @PedroDiez @shilpa-padgaonkar @jlurien

@rartych or @PedroDiez again requesting if we could align on terminationReason SUBSCRIPTION_UNPROCESSABLE?

[PedroDiez]

@rartych From DeviceLocation side we aggree on using the terminationDescription. ✅ The second proposal from @bigludo7 was to add the terminationReason SUBSCRIPTION_UNPROCESSABLE.
Can we also align on that?
cc @PedroDiez @shilpa-padgaonkar @jlurien

@rartych or @PedroDiez again requesting if we could align on terminationReason SUBSCRIPTION_UNPROCESSABLE?

I think we can align on that and set formally in MetaRelease Spring 25. Ok with the decsision taken in Device Location

[bigludo7]

I think we are aligned on this.
I can make a proposal in a PR for update in the guideline & event-subscription-template.yaml
@rartych you can assign on me & add subscriptions tag :)

[shilpa-padgaonkar]

@maxl2287 @PedroDiez @bigludo7 Fine for me to agree on terminationReason and SUBSCRIPTION_UNPROCESSABLE