We haven’t build the subscribe+catchup logic into the API directly (there are too many variations on what people might want to make it feasible to easily pick one and satisfy everyone). However, there are a number of new things which make implementing it relatively straightfoward.
The important thing if you want “at-least-once” or “exactly-once” guarantees for rebuilding persistent view models is that you store your last processed position transactionally with whatever work you’re doing as a result of the event. You subscribe using something like this:
connection.SubscribeToAll(false, EventAppeared, SubscriptionDropped);
The subscription method returns an acknolwedgement containing a position from which you are guaranteed to see events over the subscription (note it doesn’t guarantee you WON’T see earlier ones, but this is a straightforward position comparison to mitigate). EventAppeared is an Action. ResolvedEvent is a new type introduced during our client API changes recently. As you process events appearing over the subscription, you can find the logical position in the transaction file in the OriginalPosition field. A position is a tuple of prepare and commit position, both of which are longs, represented by the Position type.
When your subscriber restarts, you can do the following:
Subscribe to all, enqueing events as they appear. Note the position contained in acknowledgement
Read from the last seen position until you reach the end of the stream OR the position contained in the subscription ACK, processing each event as necessary.
Start processing from the queue of events appearing over the subscription, discarding any which are earlier than you want.
The same basic process applies if you want to process events from an individual stream (using SubscribeToStream) instead of the all stream.
We’ll post some sample code for this shortly, but hopefully this description helps?