# Proposed removal of scheduler checkpointing capability

**URL:** <https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275>\
**Category:** Cylc Announce\
**Created:** [October 14, 2020, 9:33pm UTC](https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275 "2020-10-14T21:33:49Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [October 14, 2020, 9:33pm UTC](https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275/1 "2020-10-14T21:33:49Z")

</div>

The Cylc scheduler program records and continually updates its state - what tasks are currently active and what state they are in, etc. - in the “run database”. If you stop the run, or the scheduler gets killed (e.g. if the host VM goes down), this is the “latest state” snapshot that we can initialize the scheduler with to do a restart.

Cylc 7 also supports arbitrary named checkpoints via the `cylc checkpoint` command, so you can restart at predetermined earlier points in the workflow instead of the latest state.

However, we are proposing to remove named checkpointing from Cylc 8. As far as we know it is not well used, and Cylc 8 has something we call “reflow” that should be much better (you can trigger a new “flow” at any point in the graph, with no DB checkpoint needed).

So: **if you rely on checkpointing in Cylc 7, please let us know (on this forum) how you use it, so that we can be sure Cylc 8 will support your needs without checkpointing.**

Regards,  
Hilary

---

<div class="post-metadata">

**Author:** ![russb](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/russb/32/150_2.png) [@russb](https://cylc.discourse.group/u/russb)\
**Post date:** [October 15, 2020, 3:48pm UTC](https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275/2 "2020-10-15T15:48:00Z")

</div>

To confirm, this is just for the **named** checkpoints? Not the checkpointing automatic/recovery capability? We very much use the automatic checkpointing for recovery but not the named checkpoints.

---

<div class="post-metadata">

**Author:** ![oliver.sanders](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/oliver.sanders/32/110_2.png) [@oliver.sanders](https://cylc.discourse.group/u/oliver.sanders)\
**Post date:** [October 15, 2020, 4:15pm UTC](https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275/3 "2020-10-15T16:15:24Z")

</div>

Yes, this is just for named checkpoints created with the `cylc checkpoint` command, the database would continue to preserve the current state of the workflow allowing for restarts and crash recovery.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [October 22, 2020, 9:56pm UTC](https://cylc.discourse.group/t/proposed-removal-of-scheduler-checkpointing-capability/275/4 "2020-10-22T21:56:34Z")

</div>

(OK great, as pretty much expected no one has chimed in in favor of named checkpoints … we’ll update you in the decision in due course.)