Server: ISubscription publishes 11 members of internal publish-pipeline protocol on its public interface

[marcschier]

Summary

ISubscription has 42 members. Eleven of them are publish-pipeline collaboration protocol with SubscriptionManager and SessionPublishQueue — internal machinery published on a public interface, where any holder of an ISubscription can call them and corrupt the publishing state machine.

Evidence

Subscription/ISubscription.cs — 42 members over Subscription (3,471 lines).

The 11 protocol members:

Member	Purpose
ItemReadyToPublish	monitored item signals data available
ItemNotificationsAvailable	monitored item signals queued notifications
QueueOverflowHandler	queue overflow callback
PublishTimerExpired	publish timer tick
PublishTimeout	timeout notification message
SubscriptionTransferred	transfer notification message
AvailableSequenceNumbersForRetransmission	retransmission bookkeeping
Acknowledge	sequence number acknowledgement
ResendData	resend request
SessionClosed()	session teardown
SessionClosed(ISession)	session teardown, overload

Why this matters

These are called by exactly two collaborators — SubscriptionManager and SessionPublishQueue — but they sit on the public interface. A node manager reaching through IServerInternal.SubscriptionManager.GetSubscriptions() can call PublishTimerExpired() or QueueOverflowHandler() directly and drive the publishing state machine into an inconsistent state. Nothing in the type system prevents it.

The interface is also the test surface, so tests of subscription behaviour are invited to drive the protocol directly rather than asserting observable outcomes.

The behaviour behind the seam is real

This is not a pass-through — the publishing machinery is substantial:

Module	Lines
Subscription.cs	3,471
SessionPublishQueue.cs	1,071
SentMessageQueue.cs	449
Total	~5,000

Deletion test

Delete the 11 members from the public interface: complexity reappears, but only inside SubscriptionManager and SessionPublishQueue, which are the only legitimate callers. That is relocation into an internal seam, not duplication across callers.

Proposed direction

Move the publish-pipeline protocol to an internal seam consumed only by SubscriptionManager and SessionPublishQueue. Leave the service-set operations (CreateMonitoredItemsAsync, ModifyMonitoredItemsAsync, DeleteMonitoredItemsAsync, SetMonitoringModeAsync, SetPublishingMode, Publish, Republish, Modify, ConditionRefreshAsync, SetTriggering, TransferSessionAsync, …) on ISubscription.

Expected result: 42 → ~25 members, no behaviour change, no plugin-API break.

Open question

Does durable-subscription restore require external access to any of the 11? ToStorableSubscription(), SetSubscriptionDurable() and AvailableSequenceNumbersForRetransmission() interact with the persistence path (Subscription/Persistence/), so the internal seam must still serve ISubscriptionStore and ISubscriptionRetransmissionStore. See docs/DurableSubscription.md.

Constraints

• 1.5.378 compatibility — additive; mark the moved members [Obsolete] on ISubscription and forward to the internal seam during transition.
• Must continue to support TransferSubscriptions (docs/TransferSubscription.md) and durable subscriptions.
• Tests that currently drive the protocol directly should be replaced with tests asserting observable outcomes through the service-set operations — replace, don't layer.

Dependency category

In-process. Pure computation and in-memory state; no port required. The persistence seams (ISubscriptionStore, IMonitoredItemQueueFactory, ISubscriptionRetransmissionStore) already exist and are reused unchanged.

Verified against commit e73e71184.

[marcschier]

Adapter count, before anyone starts extracting

Measured while finishing #4187, because that issue turned on the same question.

ISubscription has exactly one production adapter: src/Opc.Ua.Server/Subscription/Subscription.cs. The other matches in a naive search are the unrelated client SubscriptionManager and dependency-injection registrations, neither of which implements this interface.

One adapter means the seam is hypothetical; two means it is real.

Why that changes the proposal

This issue proposes extracting the 11 publish-pipeline members into their own seam. With a single adapter, that does not remove a hypothetical seam — it creates a second one, and leaves both to be maintained.

The same reasoning applied to ISession in #4187, where the conclusion was reduce, don't split, and the interface went from 38 members to 14 by deleting what had no caller and routing pass-throughs into the module that already owned the behaviour. None of that needed a new interface.

The likely right answer here is the same shape: take the publish-pipeline members off ISubscription — internal, or on the concrete Subscription — rather than re-homing them behind a new abstraction. Subscription is 3,106 lines behind a 32-member interface, so there is room to reduce.

What to do first

Measure before designing, in this order:

1. Count every member by read site across src, samples and tests, split by area. The number that decides whether a member belongs on the interface is production consumers outside Opc.Ua.Server.
2. Apply the deletion test to what that turns up, as its own commit, before designing anything against the interface.
3. Migrate the heaviest real consumer and let it correct the design — every design correction in Server: ISession mixes five concerns and leaks untyped object state for history continuation points #4187 came from doing that, not from reasoning about the interface.

Sequencing

Not started deliberately. Four PRs (#4188, #4193, #4197, #4199) are green and unreviewed, and this change is large enough that a review comment on the bottom of that stack would force a rebase through six branches. Worth doing once the stack lands.