Thanks David, it’s clear now. In my case, the x2 will be recovered by the last checkpoint if it was processed and wait few seconds to be checkpointed Or my source can be rewind and it will replay the x2.
> 2022年7月12日 09:10，David Anderson <dander...@apache.org> 写道： > > This is, in fact, the expected behavior. Let me explain why: > > In order for Flink to provide exactly-once guarantees, the input sources must > be able to rewind and then replay any events since the last checkpoint. > > In the scenario you shared, the last checkpoint was checkpoint 2, which > occurred before x2 was processed. The x3 input caused a failure, and the > state from checkpoint 2 was restored. This state contained only [a, b, c]. > > Since sockets don't rewind and replay their input, the x2 has been lost -- it > wasn't checkpointed, nor did you repeat it after the failure. > > If the source had been something that supported rewind and replay, like > kafka, the events since the offsets stored in the checkpoint would have been > automatically re-processed and nothing would have been lost. > > Hope that was helpful, > David
