Motivation
Currently, the Checkpoint mechanism in Functionstream only covers the input-side offsets and output-side flushes, leaving the WASM processor's internal state unpersisted. Consequently, if a task crashes or restarts, the internal business state (such as accumulators, counters, or aggregation windows) is completely lost, even though the data offset continues to advance. This breaks local state consistency, causes silent data corruption, and prevents the system from reliably supporting stateful WASM applications.
Objective
Achieve local state consistency and true exactly-once processing semantics for Functionstream WASM tasks. The goal is to ensure that when a Checkpoint signal is triggered, the internal state of the WASM processor is synchronously captured and persisted. This state snapshot must achieve a strict atomic binding with both the input-side Offset and the output-side Flush—ensuring that either all three components succeed together, or the entire Checkpoint safely fails and aborts.
Motivation
Currently, the Checkpoint mechanism in Functionstream only covers the input-side offsets and output-side flushes, leaving the WASM processor's internal state unpersisted. Consequently, if a task crashes or restarts, the internal business state (such as accumulators, counters, or aggregation windows) is completely lost, even though the data offset continues to advance. This breaks local state consistency, causes silent data corruption, and prevents the system from reliably supporting stateful WASM applications.
Objective
Achieve local state consistency and true exactly-once processing semantics for Functionstream WASM tasks. The goal is to ensure that when a Checkpoint signal is triggered, the internal state of the WASM processor is synchronously captured and persisted. This state snapshot must achieve a strict atomic binding with both the input-side Offset and the output-side Flush—ensuring that either all three components succeed together, or the entire Checkpoint safely fails and aborts.