Repository navigation
Hand tracked acknowledgements over when a subscription transfers to another session - #4942
Conversation
…nother session Fixes #4930
There was a problem hiding this comment.
🟡 Changes recommended
Critical transfer races can acknowledge messages before replay retrieves them and erase confirmations during session handover, causing replay failures and duplicate acknowledgement outcomes.
2 open issues
What changed in this PR
This PR addresses #4930 by handing tracked acknowledgements between classic subscription engines when a subscription moves to another session, aiming to preserve confirmations and prevent duplicate outcomes.
Changes:
- Adds release and adoption logic for tracked acknowledgements.
- Integrates handover into session transfers, with destination configuration governing subsequent handling.
- Adds an engine-level regression test and documents cross-session behavior.
| File | Description |
|---|---|
tests/Opc.Ua.Client.Tests/Session/ClassicSubscriptionEngineTests.cs |
Tests acknowledgement release, adoption, and retained-message tracking. |
src/Opc.Ua.Client/Subscription/Acknowledgements/IAcknowledgementTracker.cs |
Adds a release contract that returns confirmation state. |
src/Opc.Ua.Client/Subscription/Acknowledgements/ConfirmedAcknowledgementProvider.cs |
Implements release without reporting an outcome. |
src/Opc.Ua.Client/Session/Subscription/ClassicSubscriptionEngine.cs |
Adds acknowledgement release and adoption logic. |
src/Opc.Ua.Client/Session/Session.cs |
Invokes handover after subscription transfer. |
docs/Subscriptions.md |
Replaces the known limitation with handover and configuration behavior. |
Review effort: Balanced
Code coverage✅ Coverage gate passed.
Uncovered changed lines
Coverage is above the recorded baseline - consider ratcheting Thresholds live in |
There was a problem hiding this comment.
🟡 Changes recommended
Acknowledgement lifecycle bugs can lose confirmations and allow duplicate terminal outcomes after delayed Republish responses, while a throwing subscription-change handler can leave released handles without any terminal outcome.
2 open issues
2 resolved since last review
Review effort: Balanced
There was a problem hiding this comment.
🟡 Changes recommended
Unresolved acknowledgement and republish lifecycle bugs can produce duplicate terminal outcomes, retain deleted subscriptions, and leave transferred-message reservations stuck.
4 open issues
2 resolved since last review
Review effort: Balanced
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4942 +/- ##
========================================
Coverage 83.37% 83.37%
========================================
Files 3525 3525
Lines 512661 513026 +365
Branches 87203 87285 +82
========================================
+ Hits 427428 427743 +315
- Misses 56277 56323 +46
- Partials 28956 28960 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Description
With an acknowledgement observer or provider configured, transferring a classic
Subscriptionto a differentSessiondid not hand its tracked acknowledgements to the new session's engine. Outcomes were reported twice, and inAfterConfirmationmode the confirmations were lost.Now the previous engine releases the subscription's tracked acknowledgements without an outcome. The new engine tracks those whose message the server still holds and keeps the confirmation, and ends the others as
NotRetained, so each acknowledgement ends exactly once. The new session's configuration governs; if it has no acknowledgement configuration, the previous session ends them asOwnerRetired.docs/Subscriptions.mdreplaces the known limitation with this behavior.Related Issues
Checklist
Validation:
dotnet test tests\Opc.Ua.Client.Tests\Opc.Ua.Client.Tests.csproj -f net10.0 --filter "FullyQualifiedName~ClassicSubscriptionEngineTests|FullyQualifiedName~Acknowledgement"passed (124/124). net48 and the full solution were not run.