I am adding TTL to ValueState in one ProcessFunction in one of my Flink apps. The Flink app has multiple other kinds of state both in this one ProcessFunction and in other operators. I understand that adding TTL to ValueState makes it non-backwards compatible. However, I was wondering if I could use the AllowNonRestoredState option to restore the rest of the application's state from the snapshot and have Flink just skip restoring the state for the one ValueState I add TTL to? Essentially, I was hoping for a little more insight into what AllowedNonRestoredState does. From the docs, it seems like it only works in situations where state was dropped all together, not in cases where the state still exists but has been modified.
AllowedNonRestoredState simply allows a job to start from a state snapshot (a savepoint or checkpoint) that contains state that has nowhere to be restored to in the job being started. In other words, some state was dropped.
Instead of trying to get Flink to not restore state for a particular ValueState, you could leave the old ValueState alone, while also introducing a new ValueState (with state TTL). When reading the new ValueState, if it's null, you could then migrate forward the old value.
However, I think it would be preferable to do a complete, one-time migration using the State Processor API (as I proposed here).