Correct the scheduler failover description

Merged
YO
1d ago
+14-11

Summary

The scheduling page promised takeover within 30 seconds and omitted the shared storage requirement. Failover behavior is now described as the code implements it.

Changes

  • State that standbys need the same DAGU_HOME on shared storage
  • Give takeover times for a clean stop (about 5 seconds) and a crash (usually 23 to 35 seconds, plus startup)
  • State that runs on a failed host are marked failed and link the retry and restart policies
  • Align the architecture and CLI pages, and document multiple coordinators

Times are derived from the code defaults (7s heartbeat, 30s stale, 5s retry). Failure testing and a full high availability guide follow separately.

pnpm build passes.


Summary by cubic

Corrects the scheduler failover documentation so it matches how the HA code actually behaves. The docs previously promised takeover within 30 seconds and never mentioned that standbys require shared storage.

Changes

  • State that every scheduler must use the same effective data directory and DAG directory on shared storage, such as NFS; a shared DAGU_HOME provides both unless a path such as DAGU_DATA_DIR overrides it.
  • Give takeover times for a clean stop (~5 seconds) and a crash (usually 23–35 seconds plus startup, based on the 7s heartbeat, 30s staleness, and 5s retry defaults), and note that clocks must be synchronized because a standby judges lock age with its own clock.
  • Note that failover is not exactly-once: a scheduler paused past the stale threshold can dispatch a slot after another instance has taken over, so a slot can run twice.
  • Note that runs on a failed host are marked failed rather than resumed; use retry_policy for scheduled DAGs, since restart_policy cannot combine with a schedule, while services restart through their restart_policy.
  • Align the architecture and CLI pages: document workers failing over between several coordinators, which must share server state and differ by hostname or port.

Summary by CodeRabbit

  • Documentation
    • Clarified that workers fail over among the coordinators they are configured to use.
    • Expanded scheduler guidance to explain active and standby instances, shared state, and the shared storage required for high availability.
    • Documented takeover timing for clean shutdowns and stale locks, and noted that runs on a failed host are marked failed rather than resumed. DAG-level retry or restart policies can be used for reruns.