Graceful shutdown on errors in Node.js - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when an uncaught exception occurs in this Node.js server?

Consider this Node.js server code snippet. What will be the output behavior when an uncaught exception is thrown inside the request handler?

Node.js

import http from 'http';

const server = http.createServer((req, res) => {
  if (req.url === '/error') {
    throw new Error('Unexpected error');
  }
  res.end('Hello World');
});

server.listen(3000);

process.on('uncaughtException', (err) => {
  console.error('Caught exception:', err.message);
  // No server.close() called here
});

A The server logs the error message and shuts down immediately without closing connections.

B The server logs the error message but continues running and accepts new requests.

C The server crashes without logging anything.

D The server logs the error and gracefully closes existing connections before exiting.

💡 Hint

Think about what happens if you catch an uncaughtException but do not close the server.

The 'uncaughtException' handler logs the error but since server.close() is not called, the server keeps running and accepts new requests. This is risky because the server state may be unstable.

❓ state_output

intermediate

What is the state of the server after calling server.close() inside an error handler?

Given this code snippet, what is the state of the server after an error triggers the 'uncaughtException' handler that calls server.close()?

Node.js

import http from 'http';

const server = http.createServer((req, res) => {
  if (req.url === '/fail') {
    throw new Error('Fail');
  }
  res.end('OK');
});

server.listen(3000);

process.on('uncaughtException', (err) => {
  console.error('Error:', err.message);
  server.close(() => {
    console.log('Server closed');
    process.exit(1);
  });
});

A The server stops accepting new connections but keeps existing connections open until they finish.

B The server immediately terminates all connections and exits.

C The server continues accepting new connections during server.close().

D The server ignores server.close() and keeps running.

💡 Hint

Remember what server.close() does in Node.js.

Calling server.close() stops the server from accepting new connections but allows existing connections to complete before the callback runs.

🔧 Debug

advanced

Why does this graceful shutdown code not exit the process?

This code aims to gracefully shut down the server on an unhandled rejection but the process never exits. What is the cause?

Node.js

import http from 'http';

const server = http.createServer((req, res) => {
  if (req.url === '/reject') {
    Promise.reject(new Error('Rejected promise'));
  }
  res.end('OK');
});

server.listen(3000);

process.on('unhandledRejection', (reason) => {
  console.error('Unhandled rejection:', reason.message);
  server.close(() => {
    console.log('Server closed');
  });
  // Missing process.exit()
});

A The error is swallowed silently and does not trigger the handler.

B The server.close() callback never runs because the server is not listening.

C UnhandledRejection event does not catch promise rejections inside request handlers.

D The process does not exit because process.exit() is not called after server.close().

💡 Hint

Think about what happens after server.close() finishes.

Without calling process.exit(), the Node.js process keeps running even after the server closes, because there may be other open handles or timers.

📝 Syntax

advanced

Which option correctly handles graceful shutdown on SIGINT signal?

Choose the code snippet that correctly listens for SIGINT and gracefully shuts down the server before exiting.

A

process.on('SIGINT', () => {
  server.close(() => {
    console.log('Server closed');
    process.exit(0);
  });
});

B

process.on('SIGINT', () => {
  console.log('Server closed');
  server.close(() => process.exit(0));
});

C

process.on('SIGINT', () => {
  server.close();
  console.log('Server closed');
  process.exit(0);
});

D

process.on('SIGINT', () => {
  process.exit(0);
  server.close(() => console.log('Server closed'));
});

💡 Hint

Remember server.close() is asynchronous and process.exit() should be called after it finishes.

Option A waits for server.close() to finish before calling process.exit(0), ensuring graceful shutdown. Other options call process.exit() too early or log before closing.

🧠 Conceptual

expert

Why is it risky to continue running a Node.js server after catching an uncaught exception without shutting down?

Select the best explanation for why continuing to run a Node.js server after an uncaught exception without shutting down can cause problems.

A Uncaught exceptions are always harmless and can be ignored safely.

B The server will automatically restart, so no action is needed.

C The server may be in an inconsistent state, leading to unpredictable behavior or security issues.

D Node.js prevents any further requests after an uncaught exception automatically.

💡 Hint

Think about what happens to program state after an unexpected error.

Uncaught exceptions can leave the server in an unstable state. Continuing to run risks corrupted data, memory leaks, or security vulnerabilities. It's best to shut down and restart cleanly.

Practice

1. What is the main purpose of implementing a graceful shutdown in a Node.js application?

easy

A. To restart the server automatically after an error

B. To log all incoming requests for debugging

C. To increase the server's performance under load

D. To stop accepting new requests and clean up resources before exiting

Solution

1. Step 1: Understand graceful shutdown concept

   Graceful shutdown means stopping new work and cleaning up before the app exits.

2. Step 2: Identify the main goal

   The goal is to avoid abrupt termination by closing servers and resources properly.

3. Final Answer:

   To stop accepting new requests and clean up resources before exiting -> Option D

4. Quick Check:

   Graceful shutdown = stop new work + cleanup [OK]

Hint: Remember: graceful shutdown means clean exit, not restart [OK]

Common Mistakes:

• Confusing graceful shutdown with automatic restart
• Thinking it improves performance directly
• Assuming it only logs requests

2. Which of the following is the correct way to listen for an uncaught exception to trigger graceful shutdown in Node.js?

easy

A. process.on('uncaughtException', handler)

B. process.addListener('error', handler)

C. process.listen('uncaughtException', handler)

D. process.catch('uncaughtException', handler)

Solution

1. Step 1: Recall Node.js event listening syntax

   Node.js uses process.on(event, handler) to listen for events.

2. Step 2: Identify the correct event for uncaught exceptions

   The event name is 'uncaughtException', so process.on('uncaughtException', handler) is correct.

3. Final Answer:

   process.on('uncaughtException', handler) -> Option A

4. Quick Check:

   Use process.on for events like uncaughtException [OK]

Hint: Use process.on(event, handler) for error events [OK]

Common Mistakes:

• Using process.catch instead of process.on
• Using wrong event names like 'error' for uncaughtException
• Confusing listen with on

3. Consider this Node.js code snippet handling graceful shutdown:

const server = require('http').createServer();
process.on('SIGINT', () => {
  console.log('Shutdown signal received');
  server.close(() => {
    console.log('Server closed');
    process.exit(0);
  });
});
server.listen(3000, () => console.log('Server running'));

What will be the output if you press Ctrl+C in the terminal?

medium

A. Shutdown signal received\nServer running\nServer closed

B. Server running\nShutdown signal received\nServer closed

C. Server running\nServer closed\nShutdown signal received

D. Server closed\nShutdown signal received\nServer running

Solution

1. Step 1: Understand server start and signal handling order

   The server logs 'Server running' when it starts listening. On Ctrl+C, SIGINT triggers the handler.

2. Step 2: Trace the shutdown logs

   On SIGINT, it logs 'Shutdown signal received', then closes the server, then logs 'Server closed'.

3. Final Answer:

   Server running\nShutdown signal received\nServer closed -> Option B

4. Quick Check:

   Startup log first, then SIGINT logs in order [OK]

Hint: Remember: server.listen logs first, then signal handler logs [OK]

Common Mistakes:

• Mixing order of logs on startup and shutdown
• Assuming server closes before signal logs
• Ignoring asynchronous server.close callback

4. Given this code snippet for graceful shutdown, what is the main problem?

const server = require('http').createServer();
process.on('uncaughtException', (err) => {
  console.error('Error:', err);
  process.exit(1);
});
server.listen(3000);

medium

A. It listens on the wrong port

B. It does not log the error properly

C. It exits immediately without closing the server

D. It uses the wrong event name for errors

Solution

1. Step 1: Analyze error handling behavior

   The handler logs the error but calls process.exit(1) immediately.

2. Step 2: Check for graceful shutdown steps

   It does not close the server before exiting, which can cause abrupt termination.

3. Final Answer:

   It exits immediately without closing the server -> Option C

4. Quick Check:

   Graceful shutdown requires closing server before exit [OK]

Hint: Always close servers before calling process.exit [OK]

Common Mistakes:

• Exiting without cleanup
• Ignoring server.close in error handlers
• Assuming logging is enough

5. You want to implement a graceful shutdown that handles both SIGTERM and uncaughtException events, ensuring the server closes before exit. Which code snippet correctly achieves this?

hard

A. process.on('SIGTERM', () => { server.close(() => process.exit(0)); }); process.on('uncaughtException', (err) => { console.error(err); server.close(() => process.exit(1)); });

B. process.on('SIGTERM', () => { server.close(); }); process.on('uncaughtException', () => { process.exit(1); });

C. process.on('SIGTERM', () => { process.exit(0); }); process.on('uncaughtException', () => { process.exit(1); });

D. process.on('SIGTERM', () => { console.log('Terminated'); }); process.on('uncaughtException', (err) => { console.error(err); });

Solution

1. Step 1: Check handling of SIGTERM

   process.on('SIGTERM', () => { server.close(() => process.exit(0)); }); process.on('uncaughtException', (err) => { console.error(err); server.close(() => process.exit(1)); }); closes the server and then exits, which is correct for graceful shutdown.

2. Step 2: Check handling of uncaughtException

   process.on('SIGTERM', () => { server.close(() => process.exit(0)); }); process.on('uncaughtException', (err) => { console.error(err); server.close(() => process.exit(1)); }); logs the error, closes the server, then exits with error code, ensuring cleanup.

3. Final Answer:

   process.on('SIGTERM', () => { server.close(() => process.exit(0)); }); process.on('uncaughtException', (err) => { console.error(err); server.close(() => process.exit(1)); }); -> Option A

4. Quick Check:

   Close server before exit on signals and errors [OK]

Hint: Always close server before exit on signals and errors [OK]

Common Mistakes:

• Exiting immediately without closing server
• Not logging errors on uncaughtException
• Ignoring asynchronous server.close callback