Error "Unexpected SequenceNumber"

[atimin]

UA Expert sometimes reports about Unexpected SequenceNumber when it subscribed on some variable of the server on Ubuntu:

19:57:37.406 | General |     | Error: UaSessionPrivate::publishCallback - KeepAlive returned unexpected SequenceNumber (expected=2, received=1)
19:57:37.406 | General |     | Warning: Notifications missing, lastSequenceNumber=1 newSequenceNumber=1

I have the same error with Prosys OPC UA Java SDK on Windows.

OS: Ubuntu 18.04 or Windows 10
Client: UA Expert, Prosys OPC UA Java SDK
Stacks Versions: 3.6.0-dev (test on Ubuntu), 3.3.3 (test on Windows)

UAExpert.log

[huebl]

If a data notification or an event notification is sent to the client in a publish response message, the sequence number is incremented by one. If there is a keepalive notification in the publish response, the sequence number is not increased.

The error should be corrected in Release 3.

[huebl]

The requirements for the assignment of sequence numbers are described in Specification 4.

Subscriptions have a keep-alive counter that counts the number of consecutive publishing
cycles in which there have been no Notifications to report to the Client. When the maximum
keep-alive count is reached, a Publish request is de-queued and used to return a keep-alive
Message. This keep-alive Message informs the Client that the Subscription is still active. Each
keep-alive Message is a response to a Publish request in which the notificationMessage
parameter does not contain any Notifications and that contains the sequence number of the
next NotificationMessage that is to be sent. In the clauses that follow, the term
NotificationMessage refers to a response to a Publish request in which the notificationMessage
parameter actually contains one or more Notifications, as opposed to a keep-alive Message in
which this parameter contains no Notifications. The maximum keep-alive count is set by the
Client during Subscription creation and may be subsequently modified using the
ModifySubscription Service. Similar to Notification processing described in (c) above, if there
are no Publish requests queued, the Server waits for the next one to be received and sends
the keep-alive immediately without waiting for the next publishing cycle.