Attach topic to c8y message conversion error

[Bravo555]

Proposed changes

Improve error reporting in c8y mapper by printing the topic when there was an error converting a message on that topic.

Example: when publishing an invalid command metadata message: $ tedge mqtt pub -r te/device/main///cmd/config_snapshot 'a'

before:
ERROR: Mapping error: expected value at line 1 column 1

after:
ERROR: Mapping error: Failed to convert a message on topic 'te/device/main///cmd/config_snapshot': expected value at line 1 column 1

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

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
526	0	2	526	100	1h37m28.907042999s

[codecov]

Codecov Report

Attention: Patch coverage is 91.66667% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/extensions/c8y_mapper_ext/src/converter.rs	91.30%	0 Missing and 2 partials ⚠️

Additional details and impacted files

📢 Thoughts on this report? Let us know!

[albinsuresh]

How about moving this MessageConversionError creation logic into the convert function and propagate the same type into wrap_errors and new_error_message functions as well, since the new_error_message function already has the logic below that creates the message on the error topic. That

[Bravo555]

wrap_errors is also used in other places where we don't have a message we're converting, for example auto entity registration. Then using the topic of a message that causes auto-registration (for example some measurement) next to any errors about registration could cause confusion

[albinsuresh]

Okay, makes sense.

In that case, we can just change the signature of the new_error_message function to accept a std::error::Error instead of ConversionError so that this whole function can be shortened as:

message_or_err
    .map_err(
        |error| MessageConversionError {
            error,
            topic: input.topic.name.clone(),
        })
    .unwrap_or_else(|error| self.new_error_message(error))

[Bravo555]

Ah, you're right, so I implemented your suggestion.

[albinsuresh]

Okay, makes sense.

In that case, we can just change the signature of the new_error_message function to accept a std::error::Error instead of ConversionError so that this whole function can be shortened as:

message_or_err
    .map_err(
        |error| MessageConversionError {
            error,
            topic: input.topic.name.clone(),
        })
    .unwrap_or_else(|error| self.new_error_message(error))