Finish active work before stopping
A release or scale-down should give work already underway a chance to finish. Wildo coordinates stopping job intake, draining active jobs and running cleanup through one shutdown sequence.
Workers and telemetry participate in the same lifecycle. The drain has a deadline, so the deployment and the application’s job behavior still need to agree on how interrupted work is retried.
Example — Let a worker finish its current deliveries
During a deployment, a worker stops accepting new jobs while its current deliveries complete. Once they finish, registered cleanup can flush telemetry and close connections. If the drain deadline expires, the process proceeds with shutdown and reports the outstanding jobs.
For engineers
Separate stopping intake from releasing resources
WorkerShutdownManagerBackendService exposes two registration points: registerStopHandler runs before draining; onShutdown runs afterward, in reverse registration order. Registering signal handlers is idempotent, and cleanup is protected against double execution across graceful and forced paths.
The following is an illustrative integration inside a custom consumer that already receives the shutdown manager and owns stopConsuming, closeConnections and processJob. These methods represent the application’s existing work; they are not additional Wildo APIs.
shutdownManager.registerStopHandler(() => stopConsuming());
shutdownManager.onShutdown(() => closeConnections());
async function runAcceptedJob() {
shutdownManager.jobStarted();
try {
await processJob();
} finally {
shutdownManager.jobCompleted();
}
}
The finally is essential: failed work must release the counter too. Stop handlers must prevent further admission; cleanup must not close a connection while accepted jobs still need it. Built-in consumers already integrate with the manager; do not count their jobs a second time.
Size the operating window around the work
The manager’s default drain period is 25 seconds. The actual process termination allowance must leave time for stop handlers and cleanup as well as the drain. A long-running job needs interruption and retry semantics appropriate to its side effects; a grace period does not make delivery exactly once.
| Stage | Responsibility |
|---|---|
| Stop handlers | Stop accepting additional work |
| In-flight counter | Track accepted work through success or failure |
| Drain deadline | Bound how long shutdown waits for that work |
| Shutdown handlers | Release resources and flush registered telemetry |
| Broker closure and exit | Finish the process lifecycle |
Telemetry registers its flush with this coordinator rather than owning a competing termination path. A hard kill cannot run that sequence. HTTP requests are not automatically included in the job counter: verify the HTTP host’s own lifecycle and the deployed termination policy separately.