Skip to content

Clarification for initialEvent for connected-network-type-subscriptions#247

Merged
akoshunyadi merged 5 commits intomainfrom
Add-initialEvent-connected-network-type-subscriptions.yaml
Jan 25, 2025
Merged

Clarification for initialEvent for connected-network-type-subscriptions#247
akoshunyadi merged 5 commits intomainfrom
Add-initialEvent-connected-network-type-subscriptions.yaml

Conversation

@bigludo7
Copy link
Collaborator

What type of PR is this?

Add one of the following kinds:

  • documentation

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

 release-note
- documentation: Clarification for initialEvent for connected-network-type-subscriptions

Additional documentation

This section can be blank.

docs

@github-actions
Copy link

github-actions bot commented Jan 23, 2025

🦙 MegaLinter status: ✅ SUCCESS

Descriptor Linter Files Fixed Errors Elapsed time
✅ ACTION actionlint 2 0 0.03s
✅ OPENAPI spectral 6 0 9.91s
✅ REPOSITORY git_diff yes no 0.01s
✅ REPOSITORY secretlint yes no 0.74s
✅ YAML yamllint 6 0 1.32s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by OX Security


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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • typo in "immediatly"
  • UNKNOWN is sent if connection [technology] can not be determined.

Copy link
Collaborator Author

@bigludo7 bigludo7 Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@akoshunyadi akoshunyadi Jan 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@akoshunyadi akoshunyadi merged commit 593a29d into main Jan 25, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Enhance API documentation

2 participants