Hi,

The design is old (10+ years), but in my personal opinion it is also sort of wrong that we use the com.prosysopc.ua.stack.core.ServerState in the first place for a “client-side status”. That ServerState comes from https://reference.opcfoundation.org/Core/Part5/v105/docs/12.6, but each of the values are a “valid status” for the server (and in theory could be Read after connecting). Or well it is a merge of both: the ‘Running’ part is “server-side”, but ‘CommunicationFault’ in the case of a connection break is “client-side”.

UaClient.getServerStatus() throws when not connected.
UaClient.getServerState() returns ServerState.Unknown when not connected i.e. when we do not have a status/state (before .connect, after .disconnect; is CommunicationFault if connection break happens).

So I understand the confusion that the ‘Unknown’ doesn’t come from ServerStatusListener.onStateChange as well. I would say the ServerStatusListener sort of … only have had a meaning between UaClient.connect and disconnect and ‘Unknown’ just has been used instead of ‘null’ when there isn’t anything better.

From the “technical side”, the PublishTask Thread of UaClient is responsible for checking the status periodically and is also the one that calls the ServerStatusListener. The PublishTask thread also handles the automatic reconnects. Thus, it must be the first thing to internally be terminated before the disconnect can continue, otherwise it can accidentally reconnect the to-be-disconnected-connection. Then later as part of the .disconnect, the previously status is cleared, effectively causing a side-effect getServerState() to once again return ‘Unknown’.

I see this could be implemented either as part of the “clearing status” (above), that would mean whatever thread calling .disconnect would be the one to call the listener. Or the PublishTask thread as it’s last action could call the listener (though at this point the connection would still be up).

Though, I do see some danger that there could be listener impls out there that do something if the state is not Running, which would cause the .disconnect to also trigger that behaviour. Thus, somewhat unclear should we change anything. I’ll discuss with others, might take some time.

P.S.
While not maybe optimal, you could call the listener yourself after .disconnect returns.