GitHub user sangkyoonnam added a comment to the discussion: Planning Flink Agents 1.0 - Brainstorming
For 1.0, I'd like to work on state compatibility tests across 1.x releases. If the 1.0 compatibility policy covers state as well as APIs, a user should be able to take a savepoint on 1.0 and restore it on a later 1.x release without losing Flink-managed agent memory or pending inputs. I couldn't find a test that restores state written by an earlier release: `RescalingTest` and `ActionStateSerializerRestoreTest` restore what the same build wrote. Flink core keeps versioned operator snapshots in Git and restores them in tests such as `WindowOperatorMigrationTest` and `CEPMigrationTest`, using `flink-migration-test-utils`. I'd propose the same kind of test for the keyed and union list state in `OperatorStateManager` and `DurableExecutionManager`, following up on #1055's goal of defining the compatibility approach after 0.4. I can take the design and implementation. Durable execution also needs an explicit upgrade contract. `ActionStateSerde` documents the action-state journal as checkpoint-scoped, with its memory-update payload guaranteed readable only with the same code and Flink version, so the policy would need to say whether in-flight actions survive an upgrade. apache/flink-web#888 already lists 0.3 action-state data as incompatible with 0.4. Should state compatibility be part of the 1.0 policy? GitHub link: https://github.com/apache/flink-agents/discussions/1327#discussioncomment-19199861 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
