Extend ConnectivityStatus with UNKNOWN

[maxl2287]

Problem description
When the service tries to call the network to get some information, but the network cannot deliver either information about DATA nor SMS, then we cannot respond with "NOT_CONNECTED", but we need to communicate to the consumer that the network was not able to deliver a current status of connection.

Possible evolution
Add a new connectivity-status UNKNOWN

[sachinvodafone]

It seems, we have a similar issue against issue-138

[murthygorty]

hmm..mm @maxl2287 why wouldn't the API return a temporary error if it is unable to determine the connectivity status?
cc: @NoelWirzius @gmuratk

[sachinvodafone]

There could be some potential use-cases for "Unknown" status:

• The network is partly down, so some services like voice calls work, but others like data or SMS don't work properly.
• When there is too much network traffic, some requests like data or SMS might be delayed or fail.
• The service provider's systems have problems, so they can't provide certain information.

[bigludo7]

Tricky question...
I checked on Device location...

• In Location Retrieval if we are not able to locate the mobile within the required freshness we send back a 422
• In location Verification if we're not able to check the mobile location we send back a 200 with a "verificationResult": "UNKNOWN"

I tend to prefer 422 for our API as easier for my perspective to differentiate "business" valuable response.

[sachinvodafone]

Thanks @bigludo7 for more insight on this and I would also prefer 422 in this case where it explicitly indicates a failure to process the request due to some unknown network issue.

[fernandopradocabrillo]

I also tend to agree with the 422. It should not be a successful response and we should not charge for something that is not client's fault.

[maxl2287]

@jlurien @bigludo7 I guess we can transform this issue into:
"Respond with HTTP-422 when the service is unable to provide information about the current connectivity".

Wdyt?

[bigludo7]

@jlurien @bigludo7 I guess we can transform this issue into: "Respond with HTTP-422 when the service is unable to provide information about the current connectivity".

Wdyt?

Yes !
Seems that we have a consensus to send back a 422 when we're not able to get the connectivity status.
We could probably make a PR for that and update this. What do you think @akoshunyadi ? are we still in time to do that for this release?

[akoshunyadi]

We have already GENERIC_422_UNABLE_TO_PROVIDE_REACHABILITY_STATUS , that's for that case, isn't it?

[bigludo7]

We have already GENERIC_422_UNABLE_TO_PROVIDE_REACHABILITY_STATUS , that's for that case, isn't it?

oh ! yes we have it already. Thanks.
So nothing to do on the yaml - we're good.

[maxl2287]

Can we close then this issue here?

[bigludo7]

Can we close then this issue here?

+1