It is fine to leave the CommitResult/RETRY outside the scope of framework. Then the framework might need to provide some hooks in the checkpoint/restore logic. because the commit happened in the post checkpoint completion step, sink needs to update the internal state when the commit is successful so that the next checkpoint won't include the committed GlobalCommT.
Maybe GlobalCommitter can have an API like this? > List<GlobalCommT> snapshotState(); But then we still need the recover API if we don't let sink directly manage the state. > List<GlobalCommT> recoverCommittables(List<GlobalCommT>) Thanks, Steven On Tue, Sep 22, 2020 at 6:33 AM Aljoscha Krettek <aljos...@apache.org> wrote: > On 22.09.20 13:26, Guowei Ma wrote: > > Actually I am not sure adding `isAvailable` is enough. Maybe it is not. > > But for the initial version I hope we could make the sink api sync > because > > there is already a lot of stuff that has to finish. :--) > > I agree, for the first version we should stick to a simpler synchronous > interface. > > Aljoscha >
