Closed Filippo-Oliva-ABB closed 1 month ago
Attention: Patch coverage is 25.00000%
with 6 lines
in your changes missing coverage. Please review.
Project coverage is 54.67%. Comparing base (
36dbdd3
) to head (1c96145
). Report is 14 commits behind head on master.
Files with missing lines | Patch % | Lines |
---|---|---|
...braries/Opc.Ua.Server/Diagnostics/MonitoredNode.cs | 25.00% | 5 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Hi team,
I’ve noticed that the validation pipeline for my pull request failed due to code coverage requirements. While I understand the importance of comprehensive testing, I encountered a challenge because the existing library does not seem to provide a complete test set for the method I fixed.
To ensure the quality and reliability of my contribution, I would appreciate any guidance or suggestions on how to proceed with creating the necessary unit tests. Alternatively, if there are existing tests that I might have overlooked, please point me in the right direction.
Thank you for your understanding and support.
Best regards
Filippo
Hi @Filippo-Oliva-ABB , no worries, the code coverage is flaky and not required to pass... the problem is that the devops pipeline was not triggered. Thats a known issue with first time PR.
/azp run
@Filippo-Oliva-ABB unfortunately testing after the merge I ran into a NullArgumentException due to this change, MontoredItem.Session can be null. Yet undecided if we roll back the change or push a fix. Investigating.
Hi @mregen, sorry for the exception thrown, I thought a MonitoredItem always had an associated Session. What are the cases where this doesn't happen?
Please feel free to reopen a PR, we need to have another look how to fix the issue.
Hi @mregen,
I could reopen a PR to add a line before copying the ServerSystemContext with the Session inclusion that checks that the MonitoredNode.Session is not null and, if so, I could skip the enqueuing of the MonitoredItem. However, after analyzing the “Session” property of the MonitoredNode class, I noticed that it refers to the Session of the related Subscription.
The MonitoredNode.Session property acquires a lock on an internal “lock object,” which does not prevent the Subscription.Session object from changing asynchronously. I could be wrong but, in other words, the MonitoredNode does not appear to be synchronized with the Subscription.
My concern is that there may be a concurrency issue. The double-check on the Session that I propose in my new PR might mitigate this issue somewhat, but it may not fully resolve it.
I hope this clarifies my concerns. Thank you for considering my input.
Best regards
Filippo
Hi @Filippo-Oliva-ABB , it looks like this issue needs more investigation. its on the backlog. Thanks, Martin
Proposed changes
It fixes this issue by including in the SystemContext (taken as an argument to the OnMonitoredNodeChanged method) the Server session related to the current MonitoredItem that is going to be passed to the QueueValue.
Related Issues
Types of changes
What types of changes does your code introduce? Put an
x
in the boxes that apply. You can also fill these out after creating the PR.Checklist
Put an
x
in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.