Function assert_locks_are_shared 

pub fn assert_locks_are_shared(app: &Application) -> Result<()>

Refuse to run a schedule whose locking is decoration.

without_overlapping and on_one_server are only as shared as the cache behind them. Over the in-process default, three machines each take their own lock, each get it, and each run: the report goes out three times, the backup runs three times, and nothing anywhere says why. The flags read as if they are doing something, which is worse than not having them.

So schedule:run and schedule:work refuse in production, and warn everywhere else. A developer running one process is not wrong to use the memory cache; a production scheduler believing a guarantee it does not have is a bug already shipped.

This is checked here, in the process that actually runs the schedule, rather than at boot — a web container refusing to serve HTTP over a scheduling concern would be a much larger outage than the one being prevented. Boot still says so out loud: see warn_if_locks_are_not_shared.