test: check publishing of telemetry data whilst mapper is down

[gligorisaev]

This PR adds a new test case to validate the behavior of ThinEdge.io when the tedge-mapper-c8y service is down, and events are published during the downtime. The test ensures that events sent via MQTT while the mapper is offline are published to Cumulocity when the service is restored.

Test Flow:

1. Stop the tedge-mapper-c8y service.
2. Publish an MQTT event with a random event type and a test message.
3. Restart the tedge-mapper-c8y service.
4. Assert that the event is correctly received and processed by Cumulocity, verifying both the event type and message content.

Proposed changes

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

#3185

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
509	0	2	509	100	1h29m38.842096999s

[reubenmiller]

@gligorisaev some general comments/improvements:

• Please use fixup commits when addressing comments explicitly related changes/problems to previously committed code (this helps keep the git commit history clean, as your second commit does not add any valuable information)

• The naming of the test suite and the filename does not suit the contract that we want to provide to users. e.g. we shouldn't be explicitly checking for the mosquitto bug, we should be checking that thin-edge.io does not lose data if a client publishes qos1 or 2 messages whilst the mapper is down (notice the commit that I pushed 54b7b0c)

• Prefer using Test Setup over Suite Setup unless you have a really good reason to use Suite Setup

• Use unique identifiers when publishing test data. This helps reduce unexpected mistakes/behaviour if whatever assertion that you're doing looks beyond the expected scope (e.g. it looks at all events in the platform instead of events for the given device)...this is the reason why your test is passing (when it shouldn't), and my test is failing (as it should)

• Use existing keywords where possible, e.g. prefer using Stop Service instead of manually running sudo systemctl stop .... The existing library keywords help the tests to be abstracted so that we can support other service managers using the same tests (e.g. SysVinit etc.)

• Prefix the library on specific keywords where the meaning matters, for example Cumulocity.Device Should Have Event/s is more clear where the events are meant to be located (e.g. in Cumulocity and not on the local MQTT broker)

• Keep the PR description up to date to reflect the purpose of the changes. The purpose of the ticket is to add coverage for offline publishing (not to test a mosquitto bug)...the mosquitto bug aspect just was the motivation to add such a test...if we had had the system test prior to upgrading to mosquitto 2.0.18, the test would of shown us that 2.0.18 has an issue (ahead of time before we used it in all of our images; system test image, rugpi image, yocto image etc.)

[reubenmiller]

@gligorisaev

• Always put the linked ticket under the Paste Link to the issue section. You can also mention the ticket link in the description as well (if provides additional context), however having the links all in the same place makes it easier to read all the PRs and the content is normalized.

[reubenmiller]

@gligorisaev Can you remove the following commits from the PR as they have been superseded by 54b7b0c:

• 84bca71
• 820755e

And can you please update the PR description to suite (as per comments):

• test: check publishing of telemetry data whilst mapper is down #3187 (comment)
• test: check publishing of telemetry data whilst mapper is down #3187 (comment)

[reubenmiller]

@gligorisaev Thanks for dropping the two other commits, but now the commit I pushed yesterday to switch back to using mosquitto 2.0.11 is missing which means the test is failing (as the system tests are still using the bugging mosquitto 2.0.18 version)

The new commits are authored by myself, so I shouldn't be reviewing it

[reubenmiller]

@gligorisaev Thanks for dropping the two other commits, but now the commit I pushed yesterday to switch back to using mosquitto 2.0.11 is missing which means the test is failing (as the system tests are still using the bugging mosquitto 2.0.18 version)

I did rebase and choose drop of my commits only (made also screenshot of it)

Then something went very wrong (maybe you didn't do a fetch and pull prior to rebasing). But anyway I've forced pushed the changes that I still had locally.

[didier-wenzek]

Approved