How does one track the offset a client should restart from, when using the completion api? From the CompletionStreamResponse would one track the offset based off of the Checkpoints ?
1 Like
In that case, if my client crashes, how do I know from what offset to subscribe?
One could imagine a client that executes just createsAndExercisess and does not listen to the transaction stream.
To completions. In order to construct CompletionStreamRequest one can specify a LedgerOffset, which is described as "This field indicates the minimum offset for completions. This can be used to resume an earlier completion stream. "
I’ll also point out that a committer is mentioned only once within the LedgerAPI spec, in reference to a submission_id? I am confused by this documentation:
If your goal is to create a crash-tolerant application that submits commands exactly once, use command deduplication:
Upon recovering from a crash, just resubmit any command where you are not sure whether you submitted it before or whether it might still be in flight. Command deduplication will take care of handling duplicate submissions. See docs for the existing command deduplication, and docs for the new command deduplication.
Other info possibly related to your question:
- If you are only interested in the outcome of commands submitted after restarting the completion stream, don’t supply any offset. It will default to the current ledger end.
- The active contract set service returns an offset at which the ACS was taken. This offset is typically used as the starting point for a flat transaction stream that informs you of changes to the ACS.
1 Like
I’m deleting my answers as those were just wrong.
Yes, each CompletionStreamResponse will also contain a Checkpoint message that contains the offset. You can use that offset to restart the stream at a later point in time to resume the stream from that offset.
1 Like
Thank you!
1 Like
I was wondering 
+1 for honesty.