Hi Martijn, Both deviations look fine. Two small things I could not find in the thread, though I may have missed them.
1. On rollback. Without a deprecation window, the way back from a problem in production would be to downgrade the jar and restore a Sink V2 savepoint onto the old SinkFunction. JdbcTableSinkMigrationITCase covers the other direction, legacy to Sink V2. Would a test for the reverse be worth it, or a release note line on what a rollback needs? 2. On the statement set caveat. I think the impact may be a little wider than the sink. StreamGraphHasherV2.generateNodeLocalHash keys each hash to the node's position in the breadth-first walk, so the timestamp inserter shifts every node hashed after it, and that can reach a keyed operator in another branch. I tried it on a synthetic two statement job, with a plain map standing in for the inserter, which the hasher sees the same way since it mixes the traversal index and not the operator class. The strict restore failed with "Cannot map checkpoint/savepoint state for operator a4beabc9... to the new program", and that id was the keyed operator rather than the sink. The same restore with allowNonRestoredState started and dropped its state. If that looks right to you, maybe the release note could also mention: - allowNonRestoredState is not a safe workaround here, it starts the job and drops keyed state upstream of the sink. - table.exec.uid.generation defaults to PLAN_ONLY, so only a compiled plan carries uids, and that has to be decided before the savepoint is taken. Best regards, Sai Krishna
