Skip to content
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

fix(#3048): don't send status update for sub-workflow operations #3050

Conversation

Bravo555
Copy link
Contributor

@Bravo555 Bravo555 commented Aug 2, 2024

Proposed changes

Avoid processing operations on a sub-workflow operation topic in OperationHandler.

To verify the fix I created two unit tests:

  • one for OperationHandler to test its public interface
  • one more permanent test in c8y_mapper_ext::tests to make sure it still
    holds even if OperationHandler implementation changes

As this check could easily be done in c8y mapper unit tests, I didn't create an integration test.

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

To avoid similar problems in the future, we should distinguish sub-workflow command ids on a type level.

…ions

Avoid processing operations on a sub-workflow operation topic in
OperationHandler.

To verify the fix I created two unit tests:
- one for OperationHandler to test its public interface
- one more permanent test in c8y_mapper_ext::tests to make sure it still
  holds even if OperationHandler implementation changes

As this check could easily be done in c8y mapper unit tests, I didn't
create an integration test.

To avoid similar problems in the future, we should distinguish
sub-workflow command ids on a type level.

Signed-off-by: Marcel Guzik <[email protected]>
Copy link

codecov bot commented Aug 2, 2024

Codecov Report

Attention: Patch coverage is 92.10526% with 6 lines in your changes missing coverage. Please review.

Project coverage is 78.0%. Comparing base (be3b850) to head (dc7c336).
Report is 82 commits behind head on main.

Files Patch % Lines
...xtensions/c8y_mapper_ext/src/operations/handler.rs 94.1% 0 Missing and 3 partials ⚠️
crates/extensions/c8y_mapper_ext/src/tests.rs 88.0% 0 Missing and 3 partials ⚠️
Additional details and impacted files
Files Coverage Δ
...xtensions/c8y_mapper_ext/src/operations/handler.rs 95.3% <94.1%> (-0.2%) ⬇️
crates/extensions/c8y_mapper_ext/src/tests.rs 92.7% <88.0%> (-0.1%) ⬇️

... and 8 files with indirect coverage changes

Copy link
Member

@rina23q rina23q left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

github-actions bot commented Aug 2, 2024

Robot Results

✅ Passed ❌ Failed ⏭️ Skipped Total Pass % ⏱️ Duration
491 0 2 491 100 1h21m49.561932s

@Bravo555 Bravo555 added this pull request to the merge queue Aug 2, 2024
Merged via the queue into thin-edge:main with commit 193ac91 Aug 2, 2024
33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants