🚨 J · Common Errors and Fixes

J · Common Errors and Fixes: This dictionary is like a **doctor's differential diagnosis handbook**: the SAME symptom (e.g.

This dictionary is like a **doctor's differential diagnosis handbook**: the SAME symptom (e.g. "the request failed") can come from dozens of DIFFERENT root causes, and a wrong diagnosis leads to wrong treatment (escalating to the wrong team). Throughout GROUP A-I (the missing dependency in B1, the middleware order in C3, the contract defect in F5, the test chain in G4), EVERY group birthed its own error class — this dictionary GATHERS them at ONE reference point. The Java equivalent is a "runbook" — knowing in advance which log, which metric to check when a production alarm fires is FAR faster than panicked random searching. So why should this dictionary be used as a REFERENCE rather than memorized? Because the exact error message you meet in a real production environment may NOT be EXACTLY here — but the 12 patterns HERE teach the WAY OF THINKING that goes "from symptom to root cause, from root cause to the right team"; this way of thinking applies to any new error you have never seen too.

The 12 errors below are based on real scenarios you saw throughout this page. Each entry includes: the symptom (the real error message), the root cause, a broken/fixed code example, and WHICH layer (client/network, server/code, contract/spec) the tester catches it in.

Diagnosing an Error by Layer

🎬 The Diagnosis Order for an Error

Symptom: request failed

A request failed — but "failed" alone does not tell you WHICH TEAM to go to.

First question: WHICH LAYER did this originate in? The Network panel (GROUP E) is the first place to check.

If the request NEVER REACHED the server (ECONNREFUSED, CORS, timeout) → Client/Network layer.

If the request REACHED but returned a wrong/silent result (201 instead of 400, empty body) → Server/Code layer.

The lesson — if the server worked correctly but does NOT match the DOCUMENT (F5) → Contract/Spec layer. Finding the right layer is the first step to escalating to the right team.

The request body is JSON, but the `Content-Type` header is missing or wrong (like `text/plain`) — the server cannot know what format to parse the body as.

400 is used when the body could NOT be parsed AT ALL (broken JSON); 422 is used when the body was parsed but violates a BUSINESS RULE (like minLength). Most APIs return 400 for BOTH cases without distinguishing — not a standards violation, but it must be EXPLICITLY stated in the contract.

Before sending a request to a different origin (even a different port counts as a different origin), the browser sends an `OPTIONS` request (preflight); if the server does NOT RESPOND with an `Access-Control-Allow-Origin` header, the browser never sends the REAL request at all.

The server is NOT listening on that port at all — either it was never started, it crashed, or the wrong port is being connected to (see C1's forgotten `app.listen`).