You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In order for the tedge-mapper-c8y status to be set to down in Cumulocity, two things need to happen:
The service_monitor_actor publishes the 102,... last will message to c8y/s/us
The bridge receives forwards this message to Cumulocity
Previously when shutting down the mapper, the service status for tedge-mapper-c8y was accurately reported as down since the bridge was running separately in mosquitto. With the built-in bridge, however, it's hit or miss whether the bridge fully processes the message before shutting down. As a result, I modified the Cumulocity bridge's last will message to include a down message for both tedge-mapper-bridge-c8y and tedge-mapper-c8y. This fixes the mapper status reporting, ensuring that tedge-mapper-c8y is marked down in Cumulocity when the mapper is stopped.
The unintentional side-effect of this is that tedge-mapper-c8y is also reported as down whenever the bridge disconnects from Cumulocity, e.g. due to network flakiness. When the bridge reconnects, it updates its own health status to be up, but doesn't update the health status of tedge-mapper-c8y since the rest of the mapper is blind to the disconnection the bridge suffered, therefore tedge-mapper-c8y remains marked as down in Cumulocity until the mapper is restarted.
To Reproduce
Run the Cumulocity mapper with the built-in bridge enabled
Observe that both tedge-mapper-c8y and tedge-mapper-bridge-c8y are marked as up on the cloud device
Disconnect from the internet and wait for the bridge to log that it has disconnected from the cloud
Observe that both tedge-mapper-c8y and tedge-mapper-bridge-c8y are marked as down on the cloud device
Reconnect to the internet and wait for the bridge to log that it has reconnected
Observe that tedge-mapper-c8y is still marked as down on the cloud device
Expected behavior tedge-mapper-c8y should not continue to be marked as down once the bridge has reconnected.
Screenshots
The text was updated successfully, but these errors were encountered:
Describe the bug
In order for the
tedge-mapper-c8y
status to be set to down in Cumulocity, two things need to happen:service_monitor_actor
publishes the102,...
last will message toc8y/s/us
Previously when shutting down the mapper, the service status for
tedge-mapper-c8y
was accurately reported as down since the bridge was running separately in mosquitto. With the built-in bridge, however, it's hit or miss whether the bridge fully processes the message before shutting down. As a result, I modified the Cumulocity bridge's last will message to include adown
message for bothtedge-mapper-bridge-c8y
andtedge-mapper-c8y
. This fixes the mapper status reporting, ensuring thattedge-mapper-c8y
is marked down in Cumulocity when the mapper is stopped.The unintentional side-effect of this is that
tedge-mapper-c8y
is also reported as down whenever the bridge disconnects from Cumulocity, e.g. due to network flakiness. When the bridge reconnects, it updates its own health status to be up, but doesn't update the health status oftedge-mapper-c8y
since the rest of the mapper is blind to the disconnection the bridge suffered, thereforetedge-mapper-c8y
remains marked as down in Cumulocity until the mapper is restarted.To Reproduce
tedge-mapper-c8y
andtedge-mapper-bridge-c8y
are marked asup
on the cloud devicetedge-mapper-c8y
andtedge-mapper-bridge-c8y
are marked asdown
on the cloud devicetedge-mapper-c8y
is still marked asdown
on the cloud deviceExpected behavior
tedge-mapper-c8y
should not continue to be marked as down once the bridge has reconnected.Screenshots
The text was updated successfully, but these errors were encountered: