Home / Everyday moves

Debugging and fixing a bug

A precise reproduction command and a complete stack trace steer the diagnosis towards the real cause of a bug, and the fix is only declared closed once a regression test reproducing the faulty case has been run and its output read.

Pasting only the last line of an error message to Claude Code leaves the bug's real cause out of view. The documented workflow for fixing a bug effectively calls for a more complete gesture: give the command that reproduces the problem and the complete stack trace, not just its last call shown on screen.

Reproduce before diagnosing

Three elements make the difference between a fix that touches the symptom and a fix that touches the cause. The exact command that triggers the bug, the entire stack trace from the entry point to the error, and a note on whether it is intermittent or constant. A bug that only appears once in ten calls does not have the same cause as a bug that fails on every call, and this distinction steers the whole diagnosis that follows.

The following example fabricates its own data to stay valid for any reader, without touching any real file of a project. A function that shares a total across a number of parts fails when that number is zero.

function partager(total, nombreDeParts) {
  return total / nombreDeParts; // aucune garde sur nombreDeParts
}

console.log(partager(90, 3));  // 30, cas normal
console.log(partager(90, 0));  // Infinity, le bug réel se cache ici

The stack trace here would point to the exact call to partager(90, 0), the reproduction command would be this isolated call, and the nature of the bug would be constant: zero parts always produces the same invalid result, never an intermittent error.

The fix does not close on the first green

Once the cause is identified, the fix is limited to the code responsible, without touching what already worked. The final gesture consists of requiring a regression test that reproduces exactly the faulty case observed, then reading its output before considering the bug closed.

function partager(total, nombreDeParts) {
  if (nombreDeParts === 0) throw new Error("nombre de parts invalide");
  return total / nombreDeParts;
}

try {
  partager(90, 0);
} catch (erreur) {
  console.log("test de régression : ", erreur.message);
}

This requirement directly echoes writing the test before the implementation: in both cases, confidence comes from an output that was run and read, not from rereading the fixed code.