At the end of the last part your app ran. Then you changed one thing, reloaded, and instead of your app you got a wall of red text and a crash. The instinct is panic: it reads like the machine broke in a language you do not speak. That wall is the single most useful thing on your screen right now, and this chapter teaches you to read it.
7.1.1What a stack trace is
A stack trace is the report a program prints the instant it crashes. It is not noise, and it is not the machine yelling at you. It is a precise record of what the program was doing the moment it failed, printed newest event first.
Each indented line under the message is a frame: one function that was running, plus the file and line it was on. Together the frames are the trail of calls that led to the crash, a breadcrumb path back toward the start.
7.1.2Top for the error, bottom for the cause
Read a trace in two moves. The very top line is the error itself: its type and a message saying what went wrong, like reading a value that was not there.
Below it, each frame called the one above it. The top frame is where the program actually blew up, and walking down the frames traces back toward what set the crash in motion. What broke sits at the top; why it broke is usually a frame or two down.
7.1.3Find the file and line
The top line is the error: something was undefined when the code expected a value. The first frame, ledger.ts:42, is where it crashed, so that is the file and line to open first. The frames beneath it show the path that got there, through summary.ts and your home page.
Most real traces bury your code under library frames you will never touch. Scan past them for the first line naming a file you wrote, usually under app/ or src/. That is where you look.
Rule of thumb: the top line tells you what broke; the first frame pointing at your own file tells you where.
7.1.4Know which kind of error you are looking at
Some of the red text you will meet is not a stack trace at all, and each kind points somewhere different. Classify it before you paste it:
| What you see | What it usually means | Where to look |
|---|---|---|
A request returns 401 or 404 | The request was wrong: not logged in, or wrong address | The code making the request |
A request returns 500 | The server crashed while handling it | The server's own logs, where a real trace waits |
| "blocked by CORS policy" | Your server did not tell the browser it was allowed to answer | The server's headers, never the frontend |
| "Cannot find module" | Something is not installed | Run your install command again |
| "address already in use" | An old copy of your app is still running | Stop that process, the code is fine |
Two of these are not bugs in your code at all, which is exactly why guessing costs you an afternoon.
7.1.5Paste it to your agent
You do not have to diagnose it alone, and you should not try to. The fastest fix is to copy the entire trace, every line, and hand it to your agent. Do not summarize it and do not paste only the top line: the frames are the context that lets the agent find the real cause fast.
This prompt turns the trace into a targeted fix instead of a guess:
Do this now: copy the full stack trace from your terminal or browser console and paste it under the prompt. Let your agent point you at the exact file and line.
