Hi,

If the Republish fails, it means that the notification is no longer on the server and thus cannot be recovered (other than via a HistoryRead, if the server supports that). Jouni might have to do follow-ups, as this functionality is very old, however I believe the intention is to control if we would even try to Republish potentially _other_ (newer time-wise) notifications that are also lost i.e. you could skip them by returning the “sequenceNumber” parameter, but you could return it sequenceNumber-1 to try to recover the last message for example.

Nowadays, assuming the server supports it, there is ResendData method (https://reference.opcfoundation.org/Core/Part5/9.2/), some quite recent SDK version added Subscription.resendData() as a helper. Though, I should note the wording of ResendData has changed in spec versions (and I think it is still … sort of wrong in the wording). But the main point of it would be that the next time the Subscription for which ResendData was called publishes, it would send a value for all MonitoredItems. However, all that is just give “a value” to the items, if the notification was lost and could not be republished the data is lost. Not sure if this is a problem for you, but if it is the only way to recover that would be via HistoryRead and the server would have to support it.

P.S.
I would also say as a purely personal opinion that if a use-case requires to get “all data points of a node”, then the only way to do it would be via HistoryRead, because sampling could miss a change (unless the server supports interval 0). So basically you would periodically HistoryRead from current time to the last known value etc. Though, this has the downside that it has maybe a bit more latency depending on the HistoryRead interval (and it does produce a bit extra work for the server as well); and not all servers do support history.