Hello,

The callback is invoked only when you subscribe to an item and specify that you want to receive all updates, without any filtering (i.e. RAW mode or "unfiltered" frequency specified; this also applies to all items subscribed to in COMMAND mode, but limited to ADD and DELETE messages).
In these cases, we suppose that missing an update has important consequences on your application, hence that the application should be informed of the issue.
Obviously, Lightstreamer does its best effort to keep all updates, by buffering them if the client is not ready to receive them or the bandwidth is low. However, it also imposes a configurable limit on the buffer (<max_buffer_size>), hence losing updates is possible.

In our documentation we meant to stress that, by knowing the issue, the application can step in and react.
But what can be done depends only on the nature of the data, hence on the application.
The simplest thing is to alert the user of the hole.
A real recovery, that is, the rescue of the lost updates, cannot be done through Lightstreamer. You can unsubscribe and resubscribe to the item, but this just ensures that you restart from a clean state.
Note that we are talking about a critical restriction of bandwidth or client processing power, hence the goal of sending all updates may be just not feasible.
In general, you should rely on unfiltered subscriptions only for items with infrequent updates, so that losing an update is nearly impossible.