[Subscriptions]: How does the Status-handling work for multiple types?

[maxl2287]

Hi,

lets imagine we have a subscription with multiple types:

{
    "protocol": "HTTP",
    "sink": "https://test-service.test.de/api/v2/notifications",
    "types": [
        "org.camaraproject.geofencing-subscriptions.v0.area-left",
        "org.camaraproject.geofencing-subscriptions.v0.area-entered"
    ],
    "config": {
        "subscriptionDetail": {
            "device": {
                "phoneNumber": "+4144444444444"
            },
            "area": {
                "areaType": "CIRCLE",
                "center": {
                    "latitude": 52.514684701182574,
                    "longitude": 13.239559913167252
                },
                "radius": 4000
            }
        },
        "initialEvent": true,
        "subscriptionMaxEvents": 10
    }
}

Now this is requested on the provider side.
The provider has created two subscriptions. One for "LEFT" and one for "ENTERED".

Now what if "LEFT" is accepted from the network and "ENTERED" not?
So "LEFT" would be "ACTIVE" but "ENTERED" not.

At the end we just have a status for the whole "overall"-subscription, but not for each subscription.
How should a provider handle here?

[patrice-conil]

Hi @maxl2287,
If I remember well, for now we only support array of one type so there is no problem.
But we will definitely have the problem you mention in the future, and we 'll have to manage multiple statuses IMHO.

[maxl2287]

Hi Patrice,

yes I know.
I am just taking a look forward while I am implementing such a provider-version and I need to take care about the List-handling anyway.
In case of not doing big changes in the future when we just allow more than one type.

[maxl2287]

But in the case that you are aware of such a conflict, I see that there is currently no defined solution for it.

[akoshunyadi]

I tend to reject the Create-Subscription request in such case. A partially fulfilled request doesn't fulfill the customer expectations and needs, so better reject it completely. The reason should be visible in the response. So if needed the customer can repeat the call with the one type.

[patrice-conil]

Hi @akoshunyadi,
I agree with you when we have synchronous statuses... but with asynchronous ones I tend to manage a status for each subscription. And in case we later receive a rejection of a subscription... we could end the global subscription with a failure.

[ilya-smirnov-berlin]

I tend not to reject but rather to set ACTIVATION_REQUESTED since we are expecting both subscription to be created on the network. If the situation where one subcription is immediatly ready and another is ready after some delay on regular base it won't be possible to create a subscription for both if we reject it.