Clarification for initialEvent for connected-network-type-subscriptions#247
Conversation
🦙 MegaLinter status: ✅ SUCCESS
See detailed report in MegaLinter reports |
|
|
||
| When ``initialEvent`` is set to ``true`` in the subscription request, a notification has to be sent immediatly to provide the connected network type of the device targeted. | ||
| If the device is not connected, `UNKNOWN` is sent as ``connectedNetworkType`` in this notification. | ||
|
|
There was a problem hiding this comment.
- typo in "immediatly"
- UNKNOWN is sent if connection [technology] can not be determined.
There was a problem hiding this comment.
For the second point @akoshunyadi. If you subscribe with initalEvent set to true and the device si not connected (suppose the device is shut off) then we did trigger any event then?
I'm fine with that but looking for feedback.
- @eric-murray & @sachinvodafone to get their view.
There was a problem hiding this comment.
I wanted to point out that UNKNOWN is defined as "can not be determined" and not "not connected". Not connected is one of the cases when it can't determined, but there are other use cases for that too.
To your question: I think we should send the initial event, even if the status is unknown.
There was a problem hiding this comment.
OK got it.
If the status can not be determined we send an inital event valued to UNKNOWN. If the mobile is not connected no event triggered. right? I update
There was a problem hiding this comment.
I'm not sure that we can differentiate why the backend couldn't deliver connectivity info. I would tend to send the UNKNOWN also for the case that the device is not connected. So for every case, when the status cannot be determined.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Clarification for initialEvent for connected-network-type-subscriptionsns.yaml
Which issue(s) this PR fixes:
Fixes #222
Special notes for reviewers:
Changelog input
Additional documentation
This section can be blank.