Efficient Debugging: Beyond the standard Breakpoint

Table of Contents

1. Challenge

   Step 1: Set up the debug environment

   Understand the debugging scenario

   Hunting down corrupted data in a large dataset by stepping through every record manually is neither practical nor fast.

   In this lab, you'll configure a VS Code debug session for a Node.js batch-ingest handler that processes 2,000 weather-station sensor readings, a handful of which carry corrupted values that skew the aggregate summary. Rather than stepping line by line, you'll set a single conditional breakpoint that filters out every clean record and pauses only on the bad ones, then confirm your findings by running the driver from the terminal.

   Review the project structure

   The lab's codebase lives in the application directory. It already contains the handler function, a driver script that runs the handler against the fixture without a live server, mock req and res objects, and the seeded fixture file.

   In this step, you'll create the VS Code debug configuration that points the debugger at the driver script.

   ### Create the launch configuration

   In the Explorer expand the folder named .vscode at the root of the project.

   Inside that folder, open the file named launch.json.

   Add the following configuration to launch.json:

   {
     "version": "0.2.0",
     "configurations": [
       {
         "type": "node",
         "request": "launch",
         "name": "Debug Batch Ingest",
         "program": "${workspaceFolder}/application/src/drivers/run.js",
         "stopOnEntry": false
       }
     ]
   }
   

   Save the file.

   VS Code will now be able to launch a Node.js debug session targeting src/drivers/run.js without pausing on the first line.

2. Challenge

   Step 2: Explore the handler and fixture

   Understand the debugging target

   With the debug configuration in place, VS Code can attach the Node.js debugger to the handler whenever you start a session. Before placing a breakpoint, read through the handler and the fixture so your condition expression targets the right line and the right fields.

   Review the handler logic

   Open src/handlers/batchIngestHandler.js and trace through the validation loop. Notice the three fields the loop inspects on each reading: humidity, temp, and timestamp. These are the fields that carry corrupted values in the fixture, and they are the fields your conditional expression will test.

   Review the fixture data

   Open fixtures/batch-2000.json and scan a handful of records to see the field names and the range of values a clean reading carries. A normal reading has a humidity value between 40 and 80, a temp value in the low-to-mid 20s (Celsius), and an ISO timestamp string. Any record that falls outside those norms is a target.

   Note: No changes are needed in this step. The goal is to build the mental model you'll apply in Step 3.

3. Challenge

   Step 3: Set a conditional breakpoint

   Add a conditional breakpoint

   A plain breakpoint on the validation line would pause on all 2,000 iterations. A conditional breakpoint pauses only when its expression evaluates to true, letting the debugger skip every clean record automatically and land directly on the ones that matter.

   Find the validation line

   Open src/handlers/batchIngestHandler.js and find the line inside the validation loop where the three corruption conditions are checked. Right-click the breakpoint gutter on that line and select Add Conditional Breakpoint from the context menu.

   Enter the breakpoint condition

   In the expression field that appears, type the following condition:

   reading.humidity > 100 || reading.temp === -9999 || reading.timestamp == null
   

   Press Enter to confirm.

   The gutter dot changes to an colored circle with an equals sign, confirming the condition is active. The debugger will evaluate this expression on every loop iteration and pause only when the result is true.

4. Challenge

   Step 4: Identify the corrupted readings

   Understand when the breakpoint will pause

   The conditional breakpoint is active and will fire only when the debugger encounters a record whose humidity exceeds 100, whose temp is -9999, or whose timestamp is null.

   Start the debug session

   Press F5, or choose Run > Start Debugging from the menu bar, to launch the debug session. VS Code starts the driver script and runs the handler against the fixture. The debugger skips every clean reading and pauses at the first record where the condition is true.

   Inspect the corrupted reading

   In the Variables pane, expand the reading object and read the field values. You will see exactly which field holds the bad value and what that value is. Note the reading's id field.

   Continue through each match

   Press F5 to continue execution. The debugger will skip all clean records and pause at the next corrupted one. Repeat this process, noting each corrupted id and its offending field, until the debug session runs to completion.

   Verify the results in the terminal

   After the session ends, run the driver directly from the terminal to see the handler's full aggregate summary.

   In the Terminal, navigate to the application folder if you aren't already there (cd application), then run:

   node src/drivers/run.js
   

   The output includes a corruptedIds array listing every reading that failed validation. Compare the IDs in that array against the readings you identified through the debugger.

   Terminal corrupted IDs array output

   {
   "total": 2000,
   "valid": 1993,
   "corrupted": 7,
   "corruptedIds": [
     "r-0312",
     "r-0587",
     "r-0891",
     "r-1043",
     "r-1456",
     "r-1789",
     "r-1944"
   ]
   }
   

5. Challenge

   Step 5: Lab complete

   Review what you learned

   You configured a VS Code debug session for a Node.js batch-ingest handler and used a conditional breakpoint to surface corrupted sensor readings from a 2,000-record fixture without stepping through a single clean entry.

   By expressing the handler's own validation conditions as the breakpoint's filter, you let the debugger do the work and paused execution only where the data was actually wrong. Running the driver from the terminal confirmed the findings the debugger surfaced, connecting the interactive session to the handler's aggregate output.

   This technique applies to any loop or repeated code path where you need to isolate a specific class of records or events.