Closed Annopaolo closed 2 years ago
Merging #64 (8633c8f) into master (496beb1) will increase coverage by
5.09%
. The diff coverage is100.00%
.:exclamation: Current head 8633c8f differs from pull request most recent head 9bdb074. Consider uploading reports for the commit 9bdb074 to get more accurate results
@@ Coverage Diff @@
## master #64 +/- ##
==========================================
+ Coverage 73.18% 78.28% +5.09%
==========================================
Files 9 11 +2
Lines 179 221 +42
==========================================
+ Hits 131 173 +42
Misses 48 48
Impacted Files | Coverage Δ | |
---|---|---|
lib/astarte_vmq_plugin/application.ex | 100.00% <ø> (ø) |
|
lib/astarte_vmq_plugin.ex | 93.54% <100.00%> (+0.56%) |
:arrow_up: |
lib/astarte_vmq_plugin/connection/synchronizer.ex | 100.00% <100.00%> (ø) |
|
...connection/synchronizer/synchronizer_supervisor.ex | 100.00% <100.00%> (ø) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
In rare corner cases (time difference < 10 ms), the
on_register
hook (reconnection) may be called before the relatedon_client_offline/gone
hook (disconnection). This is due to the distributed nature of VerneMQ (see https://github.com/vernemq/vernemq/issues/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. During reordering (at most 50ms), other kind of messages (if any) are retained in VMQ memory.Fix https://github.com/astarte-platform/astarte/issues/668.