Node.js Redis Shutdown: Keep Async Cleanup out of exit

Waiting for a Promise to close Redis inside an exit callback does not fit the process lifecycle. Before choosing a close-method name, decide when to stop admitting work and when in-flight work must finish.

The Node.js exit documentation requires synchronous work in these listeners; newly scheduled asynchronous work cannot be expected to finish. beforeExit should not be treated as a universal shutdown manager for every termination cause either.

Model cleanup as one state transition

RUNNING -> STOP_ACCEPTING -> DRAINING -> CLOSE_REDIS -> DONE
                              | deadline/error
                              v
                         RECORD_FAILURE -> FORCED_CLOSE

In this design example, SIGTERM first sets a shutting-down state so repeated signals do not start duplicate cleanup. Stop new HTTP or queue work, await already-started work within a deadline, then close Redis. If the deadline expires, record incomplete work and shutdown failure instead of reporting a normal drain.

Check the node-redis version first

The v4-to-v5 migration guide replaces quit with close and renames disconnect to destroy. Do not copy method names from older examples without checking the installed package. Distinguish graceful draining from immediate connection destruction and verify the behavior for your version.

A staging test matrix should cover idle shutdown, in-flight requests, an already-lost Redis connection, repeated SIGTERM and an expired deadline. Record admission cutoff, completed work and exit status for each. A closed socket does not prove exactly-once processing or resolution of a kernel zombie. This state diagram is design analysis, not a runtime result.