-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add temporarily invalid connection state to Known Issues #668
Comments
Additional notes: when the status converges using the heartbeat, currently we don't fire connection triggers, so external application which are feeded by triggers do not receive the updated state. |
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
In rare corner cases (time difference < 10 ms), the `on_register` hook (reconnection) may be called before the related `on_client_offline/gone` hook (disconnection). This is due to the distributed nature of VerneMQ (see vernemq/vernemq#1741), and results in an invalid device connection state in Astarte: a device may be publishing while being in a disconnected status. Introduce a check on the order of disconnection/reconnection events, and possibly reorder them if such a corner case happens. Fix astarte-platform/astarte#668. Signed-off-by: Arnaldo Cesco <arnaldo.cesco@secomind.com>
VerneMQ does not guarantee the order of hooks due to the distributed nature of the system (see vernemq/vernemq#1741 and vernemq/vernemq#1725).
This means that in some very rare corner cases (i.e. when the disconnection and reconnection of a device are closer than ~10ms, which usually happens only when two clients reuse the same client id) the connection event is emitted before the disconnection event, leading to an inconsistent state (i.e. the device is actually connected and publishing but appears as
connected: false
in the APIs).The state eventually converges to the correct one as soon as the first heartbeat from the device is received (by default, after 1 hour), but we should document this in the Known Issue section of the documentation to help users who run into this.
The text was updated successfully, but these errors were encountered: