Maintenance Drain¶

A transition-triggered drain protocol — instantiates Queue Draining

Clears queued work ahead of a scheduled maintenance, migration, or service-window transition, and marks the clean boundary between the drained state and the resumed one — inheriting its pause, policy, and completion rules from the general drain.

A scheduled maintenance window, a migration cutover, a tooling changeover — each needs the system to enter it from a known, empty-enough state rather than mid-work. Maintenance Drain is the mechanism defined by when rather than how: its own contribution is the trigger (a planned transition, not backlog age or failure) and the transition boundary — the labelled edge separating "drained, ready for the window" from "resumed after it." The actual pausing, drain policy, and completion checking it inherits from the general drain; what makes a maintenance drain a distinct mechanism is that it fires on a schedule and draws clean state-boundaries around a planned window.

Example¶

A production line is about to undergo a scheduled tooling changeover between two product runs. Two hours before the window, the maintenance-drain trigger fires: no new work orders are released onto the line (the intake pause, inherited), the work-in-process already on the line is run down to a safe stopping point (the drain policy, inherited), and when the last unit clears, the line is declared "drained to changeover state" — the transition boundary. That boundary earns its keep: it separates finishing the old run's WIP from starting the new run, so nobody confuses leftover product with the first post-changeover units. When maintenance completes, a matching re-entry boundary hands the line back to normal work-order release.

How it works¶

Bind the trigger to a planned transition. The drain fires on a scheduled maintenance start, migration cutover, or window open — not on age or failure — with a chosen lead time.
Invoke the inherited drain. Pause intake, run the queue down under the standard policy to the completion criterion — machinery it borrows rather than owns.
Mark the transition boundary. Declare a labelled "drained, ready for the window" state so the transition starts from a known point.
Mark the matching re-entry boundary. Define the edge at which normal flow resumes, so leftover pre-window work is never confused with new post-window work.

Tuning parameters¶

Lead time before the window — how early the trigger fires. Earlier guarantees a full drain but wastes idle capacity; later risks not finishing before the window opens.
Drain-to level for the window — fully empty versus a safe partial state the maintenance can tolerate. Deeper is safer but takes longer.
Boundary strictness — a hard cutover (nothing crosses the edge) versus a soft one (some carry-through allowed). Hard is unambiguous; soft is flexible but blurs pre/post state.
Re-entry coupling — resume normal flow immediately versus stage it back. Immediate is fast but can slam a cold system just brought back up.

When it helps, and when it misleads¶

Its strength is ensuring a planned transition begins from a clean, known state, and preventing the confusion of mixing pre-window and post-window work — a common source of migration errors.

It misleads because it is schedule-driven: a fixed lead time can simply be wrong. A heavier-than-expected backlog won't finish before the window, tempting either an unsafe rush or an abandoned, half-complete drain. And treating the trigger as the whole mechanism — forgetting that the pause, policy, and completion are inherited and must actually be configured — leaves the drain improvised under a deadline. The classic misuse is firing the drain on schedule but opening the window on the clock rather than on verified completion, entering maintenance with live residual work. The discipline is to gate the window on the completion criterion, not the calendar.

How it implements the components¶

drain_trigger — binds the drain to a scheduled maintenance, migration, or service window rather than to backlog age or failure.
reentry_or_transition_boundary — the labelled edges: "drained, ready for the window," and the matching hand-back when normal operation resumes.

Its pause, drain policy, and completion criterion are deliberately not its own — it inherits the intake pause and per-item policy from Graceful Queue Shutdown and the capacity and target from Backlog Burn-Down. Its unique contribution is only the trigger and the transition edges.

Instantiates: Queue Draining — it drains a queue because a planned window is coming, and marks clean edges around it.
Consumes: Graceful Queue Shutdown for the intake pause and finish policy; Backlog Burn-Down for dedicated capacity when the pre-window backlog is large.
Sibling mechanisms: Graceful Queue Shutdown · Message Queue Drain · Connection Draining · Drain Dashboard · Surge Worker Pool · Backlog Burn-Down · Incident Backlog Cleanup · Dead-Letter Queue Processing · TTL Expiration Sweep · Appointment Waitlist Clearing