Debugging Across the Seam

// 1. Did the request leave the browser?
//    Network tab, Fetch/XHR filter. No row at all -> a client bug:
//    a handler that never fired, a guard that returned early, a
//    URL built as "undefined/problems" from a missing env var.

// 2. What status came back?
//    (failed) with no status  -> network, DNS, CORS or CSP
//    401/403                  -> auth: check the Request Headers for
//                                the cookie or Authorization header
//    422                      -> read the body; it names the fields
//    5xx                      -> server side; go to the logs

// 3. Does curl reproduce it?
curl -i https://api.aicancode.org/problems \
     -H "Origin: https://aicancode.org" -b "sid=..."
//    curl works, browser fails  -> CORS, cookies, or CSP
//    curl fails too             -> a genuine server bug

// 4. Is it the payload? Compare what you SENT with what the API
//    expects. "Copy as cURL" from the network tab gives the exact
//    request, headers included.

// 5. Server logs, filtered by the request id from step 2.

// The single most useful habit: check the network tab before
// forming a theory. Most disagreements about whose bug it is end
// there.

// "CORS error" that is really a 500
//   The server crashed before the CORS middleware ran, so no headers.
//   Tell: the server log has a stack trace at the same timestamp.

// Works in Postman, fails in the browser
//   Postman sends no Origin and ignores CORS. Always a CORS or
//   cookie difference.

// 401 only in production
//   Cross-site cookie. See the domains concept.

// 401 only on the first load, then fine
//   Server-side rendering fetched without forwarding cookies.

// 422 with an empty form error
//   The field names disagree — camelCase vs snake_case — so the
//   server rejects fields the client never sent under those names.

// Works locally, 404 in CI or production
//   A case-sensitive filesystem. './Button' vs './button'.

// Intermittent failures under load
//   A connection pool exhausted, or a request timeout shorter than
//   the p99. Look at latency percentiles, not averages.

// Data appears twice
//   A retried POST without an idempotency key, or a double-submit
//   from a button that was not disabled.

// 1. A request id on every request, echoed in the response and
//    logged on both sides. One id turns "it broke yesterday" into a
//    log line. (See the errors concept.)

// 2. Structured logs, not printed strings — so you can filter
log.info("request", path=..., status=..., ms=..., user_id=..., request_id=...)

// 3. A /health endpoint that checks the database, and an uptime
//    check hitting it. Know before the user tells you.

// 4. Error tracking on BOTH ends, joined by the request id.
//    Client-side Sentry catches what never reaches your server —
//    which is precisely the class of bug this concept is about.

// 5. Alert on rate and shape: a spike in 401s means auth broke; a
//    spike in 422s usually means the frontend started sending
//    something new; a spike in 499/timeouts means something is slow.

// 6. A staging environment with real domains and real TLS. Local
//    cannot show you a cross-site cookie failure; staging can.

// The measure of a good setup is how long it takes to answer
// "which side is this on?" — minutes with the above, an afternoon
// without.