I thought I'd try to fix or workaround this by calling PublishHelper.Execute() after the transfer to consume the StatusChangeNotification but that has revealed another defect.

The test fails:

Publish().Results[0] expected 'Good', but received: BadSubscriptionIdInvalid (0x80280000)
Publish.Request.SubscriptionAcknowledgements[0] = SubscriptionId: 1, SequenceNumber: 1

However it's reasonable to expected Bad_SubscriptionIdInvalid because the session sending the PublishRequest no longer owns this subscription (it was just transferred), so it should not be allowed to acknowledge available notifications any more.

We reviewed this in a CMP call (with a longer discussion)

The TransferSubscription description in Part 4 does not discuss what happens to the queue for a subscription when it is initially created on a transfer in (i.e. the queue the the session to which a subscription was transferred. ) in this case the Subscription is transferred back into a session that had the original subscription - it could have been initialized or it could have been left over so - both getting the Good_SubscriptionTransferred or just the initial values would be possible - since the specification is silent.

we think the test should be updated to send an publish on the first session after it is transferred away, in which case you should only see the initial values when it is transferred back in. This is updating the test case and test script.

Will clone the issue for the test case - original issue will stay on test scripts