Github user uce commented on the issue:
https://github.com/apache/flink/pull/2712
Very much agree Stephan! I don't know what sounds better to native speakers
and more intuitive to users though... unresumed state or non restored state?
;-) @greghogan @jgrier do you have any input on this?
The internal behaviour is the following: The checkpoint/savepoint stores
state for each operator of the original job graph (from which the
checkpoint/savepoint was triggered) keyed by the operator ID. When a user
resumes from this checkpoint/savepoint, the checkpoint coordinator tries to map
each state (keyed by operator ID) to the operators of the new job. This PR
*allows* ;-) that some of this state is not restored. Any ideas on how to call
this?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
