After extensive review and checking of the spec, this is is not a problem. When a subscription is transferred, the objective of the message is to notify any client that are currently listening that the subscription has transferred. (i.e. there is a publish in the queue it should be dequeue and sent to the client - so the client is aware the subscription transferred.) we will clone this issue and use it as a base for a new issue that requires a new test case that includes sending publish commands down (like a well behaved client) that are just returned . The issue you are reporting is actually a misbehaving server - when you transfer a subscription to a new client it should be the queue that was on the previous client - it should not be picking up old messages that were in the old queue i.e. I transfer to from session 1 to session two message go to session 2 - queue for session 1 goes away, transfer back to session 1 I should not see anything that was left in the old queue (it could be hours old depending on the subscription time out. It should effectively be a new queue). The issue as stated is a No Fix

The behavior of the test is correct - there server behavior is incorrect.

review in call

Disagree with your analysis Paul.

The queues exist per session, and the CTT does not close the first session, and the server does not reasonably know there is not still a user waiting for a notification the subscription was transferred on the original session.

When the subscription is finally transferred back and the original session+queue receives the PublishRequest it was starved for the first thing to go out should be the Good_SubscriptionTransferred status notification.

If the CTT does not want to receive this notification it should close the original session and open a new one to transfer back to.

The correct test should be to send a publish request on the first session after the transfer - and look for the the transferred message.
The the second transfer - when it comes back to the first session -it should then just have the initial values

After a longer discussion we came to the conclusion, that the specification is silent regarding what is happening with the existing queue, when the Subscription is transferred back to Session 1. Because of that we have decided to check for the StatusChangeNotification after pushing the subscription to Session 2.
Script has been fixed following this description.

review changes in call agreed to updates and closed issue