Shutdown is part of the request lifecycle
A deploy stops Taskboard while an owner creates a task and a worker sends an invitation. Killing both processes immediately can drop responses and interrupt delivery. Graceful shutdown gives each process a bounded chance to finish its current responsibility.
The host sends a termination signal. The process marks itself unavailable for new work, stops accepting connections or claiming jobs, waits for in-flight work where possible, and closes resources.
Separate alive from ready
Liveness asks whether the process is alive enough to answer. Readiness asks whether the process can serve useful traffic. Taskboard's readiness path checks a database dependency because task operations need Postgres.
Termination signal arrives.
Stop admitting new work.
Finish current HTTP requests or current worker batch.
Close realtime connections and database resources.
Exit before the host's deadline.
An API can be alive but unready while Postgres is unavailable. Restarting an otherwise healthy process repeatedly does not repair a database outage. The hosting system needs probes with distinct purposes.
Durable work handles the remaining gap
The worker stops claiming new batches, then lets its current batch finish. If the host's deadline arrives first, a claimed job remains in Postgres. Its lease expires, and another worker can recover it.
An SMTP send might already have succeeded when termination occurs. Recovery can repeat that send. Graceful shutdown reduces interruptions but does not strengthen the external delivery guarantee to exactly once.
Clients also observe connection loss. HTTP clients may retry with the original idempotency key. Socket clients reconnect and refetch state. A deploy therefore exercises the same recovery rules as a network failure.
The timeout must fit the host's grace period. Giving Node thirty seconds while the container host kills it after twenty seconds would make the longer wait meaningless. The Compose file sets a stop grace period; read the server and worker code for the actual shutdown behavior.
Runtime signal handling is in Read api/src/server.ts and Read api/src/worker-main.ts. Container timing is in Read compose.yml.
Stop new work before closing dependencies. Bounded shutdown helps active work finish, while durable jobs and retry-safe requests recover interruptions.
Should the worker delete its current job when shutdown begins?
No. Deleting it would lose the obligation. Finish under the current claim if possible; otherwise leave durable state for lease-based recovery.