A support-ticket app shows "Save error" — diagnose across the chain
A web app at helpme.plz creates a support ticket. The ticket number is auto-filled by a generator service (format: two letters + five digits, e.g. AA12345), there is a free-text body, and a Save button. On save, the request goes to the server and is written to a database.
Action: fill auto-generated number + body "Nothing works!", click Save
Result: "Save error"
Chain: client (browser) -> network -> server (validation) -> databaseTwo questions: (1) what would you do to find the cause, and (2) where in this client→network→server→DB chain could the bug be? Diagnose the cause.
First gather evidence: open DevTools to inspect the request/response, enable a proxy, read the app logs, and debug the backend if you have access. Then reason across the full chain: a duplicate ticket number, a Cyrillic character the generator emitted, server-side validation rejecting the number or text, the DB being down, the network failing, a slow/timed-out response, or a malformed request from the frontend.
- ✗Jumping to one cause without gathering request/response evidence
- ✗Ignoring whole links of the chain (network, DB, validation)
- ✗Assuming the generator's number is always valid
- →How would the response status code narrow down which link failed?
- →Which causes would a proxy let you confirm that DevTools alone cannot?
Two parts: how to investigate, then where it can break.
How to find the cause:
- Open DevTools → Network and read the save request and its response (status code, body).
- Enable a proxy/sniffer to see and replay the exact request.
- Read the application/server logs.
- If you can reach the backend code, debug the save handler directly.
Start from the response: the status code almost always points straight at the failing link.
400 / 422 -> server validation rejected the number or the body text
409 -> uniqueness conflict: a ticket with that number already exists
500 -> the handler itself, or the DB behind it, blew up
504 -> timeout: the request arrived, the response never came back in time
(no response) -> the request never left: network, or a malformed request from the clientWhere the bug can live, walking the chain:
- Client: malformed request from the frontend, wrong content type, wrong endpoint/version.
- Network: request never reached the server, or timed out.
- Server validation: rejects the number format, rejects Cyrillic in the body, or the generator emitted a Cyrillic character into the number.
- Data: a ticket with that number already exists (uniqueness conflict).
- Database: unreachable, or the server is failing under high load with a slow response.
The discipline is to read the actual response first, rather than guessing a single cause.
