# Queued messages now deliver the moment the server comes back — not five minutes later

The delivery recovery engine drains the queue of undelivered outgoing messages on a five-minute timer. The timer's FIRST firing is five minutes after the engine starts — and the engine restarts with the server. That was fine when restarts were rare. Today the fleet shipped ten-plus releases, the server restarted roughly every ten minutes, and each up-window between restarts was shorter than boot time plus five minutes. The result, observed live for over an hour: five queued messages to the operator — including the run summary he had just asked for — survived four separate up-windows undelivered, while freshly-sent messages in those same windows went through fine. The queue protected the messages perfectly (that part of the week's fixes worked) and then never got a chance to deliver them.

The fix is one step in the engine's startup: drain the queue immediately when the engine starts, before the timer ever matters. A booted engine now means a drained backlog — the user's queued messages go out the moment the server is reachable, instead of betting on the up-window outlasting a timer. The startup drain is awaited, so "started" deterministically means "backlog handled once," which also makes the behavior directly testable.

Nothing else changes: the five-minute watchdog, the event-driven kicks, per-topic pacing, retry backoff, and the loud-purge rules all behave exactly as before. Three integration tests pin the new contract — a pre-existing backlog of connection-refused messages (the cascade signature) is delivered by startup alone, with the existing recovery and mismatch paths re-pinned around it.
