If you can hold the values in memory, you can store them in the continuation point. The continuationpoint you give (return) is NOT the one the SDK will give to the Client. SDK will give a numeric one to the client and internally tracks the continuationpoint and gives it back to you (the parameter) when the client continues. If it still continues, modify the continuationpoint (return new one) with this info so you know then new starting point for the 3rd call.

Thus, if you are not given a continuationpoint by the SDK, it is a “new” HistoryRead call by the client and it should start from the first value. If there is a continuationpoint, then it continues. And technically you can have more than one “HistoryRead” active at the same time. There is a limit of concurrent continuationpoints and client can see this, but skipping rest of the details for now. So in short the continuationpoint (a custom java object, anything you like) must contain all the info to continue the HistoryRead.

Or maybe we missed/misunderstood something? If you meant the literal “what to return”, then it is the EventFilter that tells which data should be returned (you can look at the sampleconsoleserver, but it is somewhat simple example and we do not have any complex ones).