View Issue Details

IDProjectCategoryView StatusLast Update
000965510000-004: ServicesSpecpublic2025-03-11 15:30
ReporterThilo Bellinger Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Fixed in Version1.05.06 RC1 
Summary0009655: TransferSubscriptions to same Session
Description

TransferSubscriptions is described to transfer a subscription from one session to another.
What is the expected behavior if the subscription is already owned by the calling session?
(I know it is a pretty stupid client behavior when the client tries this.)

In case of the regular behavior, the status notification with GoodSubscriptionTransferred notifies the old session that the session does no longer own the subscription.
Thus the client session does not know if the subscription was transferred by itself (and thus still owns the subscription) or if the subscription was transferred to a different session.

Is this a wrong client behavior, is it a valid operation or is it intentionally undefined behavior and recommended to not try this?
Shall the transfer operation fail and if so with which status?
Shall the server omit the GoodSubscriptionTransferred notification when the source and target session are the same?

Please clarify and update the specification.

TagsNo tags attached.
Commit Version1.05.06 RC1
Fix Due Date2025-04-30

Activities

Matthias Damm

2025-03-10 18:52

developer   ~0022498

5.14.7 TransferSubscriptions
5.14.7.3 Service results
Added text for Bad_NothingToDo:
The result is used if the subscriptionIds array is empty or if the old and new session are identical.

Thilo Bellinger

2025-03-11 10:17

reporter   ~0022513

The solution sounds a bit confusing, so I ask to be completely clear.
The entire service shall fail and do nothing if any of the selected subscriptions is already attached to the session?
I would have expected an operation result, but it is true that a good, bad or uncertain operation result would be confusing.
I assume the goal is to prevent a special handling for the single transfer operation, too much complexity for too few benefit.

A client which got out of kilter and forgot which subscriptions it already has may have problems to recover.
On the other hand side, there are ways to test which of the known subscriptionIds are owned by the session, like GetMonitoredItems.

Matthias Damm

2025-03-11 15:29

developer   ~0022516

Agreed to return BadNothingToDo in the operation level result instead of service level

Table 102 – TransferSubscriptions Operation Level Result Codes
Added
Bad_NothingToDo
See Table 182 for the description of this result code.
This result code is returned if the Subscription is already owned by the Session used to call TransferSubscription.

Jim Luth

2025-03-11 15:30

administrator   ~0022517

Agreed to changes edited in F2F.

Issue History

Date Modified Username Field Change
2024-07-10 09:45 Thilo Bellinger New Issue
2025-02-25 16:45 Jim Luth Assigned To => Matthias Damm
2025-02-25 16:45 Jim Luth Status new => assigned
2025-02-25 16:46 Jim Luth Product Version 1.05.03 =>
2025-02-25 16:46 Jim Luth Commit Version => 1.05.06 RC1
2025-02-25 16:46 Jim Luth Fix Due Date => 2025-04-30
2025-03-10 18:52 Matthias Damm Status assigned => resolved
2025-03-10 18:52 Matthias Damm Resolution open => fixed
2025-03-10 18:52 Matthias Damm Fixed in Version => 1.05.06 RC1
2025-03-10 18:52 Matthias Damm Note Added: 0022498
2025-03-11 10:17 Thilo Bellinger Status resolved => feedback
2025-03-11 10:17 Thilo Bellinger Resolution fixed => reopened
2025-03-11 10:17 Thilo Bellinger Note Added: 0022513
2025-03-11 15:29 Matthias Damm Status feedback => resolved
2025-03-11 15:29 Matthias Damm Resolution reopened => fixed
2025-03-11 15:29 Matthias Damm Note Added: 0022516
2025-03-11 15:30 Jim Luth Status resolved => closed
2025-03-11 15:30 Jim Luth Note Added: 0022517