Extend ConnectivityStatus with `UNKNOWN`

camaraproject / DeviceStatus

Repository to describe, develop, document and test the Device Status API family

Apache License 2.0

11 stars 31 forks source link

Extend ConnectivityStatus with `UNKNOWN` #148

Open maxl2287 opened 2 months ago

maxl2287 commented 2 months ago

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 commented 2 months ago

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

murthygorty commented 1 month ago

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 commented 1 month ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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.