ErrLookup › Background articles › 'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause

'Something went wrong' / 'Request failed (500)' / 'HTTP error! status: 404' — what failed HTTP requests actually mean and how to find the real cause

'Something went wrong', 'Request failed (500)' and 'HTTP error! status: 404' are the visible faces of one error family: an HTTP request that either came back with a non-2xx status or never completed at the transport layer. A developer meets it whenever library code wraps fetch/reqwest responses — an expired session answering 401, a throttled endpoint answering 429, a server-side 500, a misconfigured base URL, or a DNS/TLS/proxy failure that produced no status at all — and the generic message often hides which one fired. This article maps the family across 28 repositories: how each library surfaces (or discards) the underlying status and cause, the causes in order of frequency, and the fixes that hold everywhere.

Distilled from 96 documented records across 28 repositories.

Background

This family sits at the HTTP client layer, at the moment a wrapper gives up on a request. Two distinct mechanisms produce it. In the first, the server answers but with a non-2xx status: Gumroad's request wrapper throws ResponseError whenever response.ok is false, Octopress's gist plugin raises RuntimeError when the final status after redirects is not 200, anything-llm throws 'HTTP error! status: ${response.status}' in executeApiCall. In the second, the transport never completes and fetch itself rejects: Chroma rethrows non-offline fetch errors as a connection error, Siyuan's SSRF-safe Go client fails at DNS, TCP dial, TLS handshake, or its fixed 30-second deadline, and GitNexus raises HttpEmbeddingError after its retry budget is exhausted. Which sub-family you are in determines whether an HTTP status exists at all, and therefore what the message can tell you.

From the caller's side, the experience splits sharply by how much detail the wrapper preserves. Some messages interpolate the status — Gumroad's 'Request failed (${response.status})' in the beneficial-owners handler, anything-llm's status-only error, Octopress's gist status code, ruflo's status-plus-response-body text — so a screenshot is diagnosable. Many others collapse every failure into a fixed string: Gumroad's 'Something went wrong.' default and 'Sorry, something went wrong. Please try again.', forem's 'An error occurred, please try again later', anything-llm's 'An error occurred while deleting the model'. Passthrough of a server-provided error message is library-specific: several Gumroad handlers show error_message verbatim when the server sent one, the tax-report handler never reads the body at all, and forem deliberately refuses to parse HTML error bodies, so 401, 429, and 500 all look identical to the user.

The transport sub-family varies just as widely in what it exposes and what it does next. Siyuan appends the raw Go error text (DNS, x509 chain problems, 'context deadline exceeded', proxy CONNECT failures). Chroma classifies fetch rejections into offline heuristics (TypeError, 'fetch failed', ENOTFOUND) versus everything else — TLS problems, undici connect timeouts, proxy CONNECT refusals. GitNexus sanitizes the reason and redacts the URL before throwing; mise caches the failure per-URL for the lifetime of the process, so every later call for the same URL returns the identical cached error; gws's events subscribe loop swallows poll timeouts but terminates the session on any other reqwest error, and its cleanup path deletes the Pub/Sub topic and subscription on the way out.

What happens after the throw is equally library-specific, and it changes the blast radius of the same family-level failure. Gumroad's section-reorder handler keeps the optimistic UI with no rollback, so the displayed order silently diverges from the server until reload. Airi's chat-sync enqueues a tombstone before the DELETE and keeps retrying it on reconnect, turning a failed request into an eventual-consistency mechanism. Paperclip's onboarding wizard logs the failure and continues, because the hired agent still runs with adapter defaults. So the same 'request failed' can mean a lost save, a guaranteed retry, or a silently skipped step.

Common causes

What usually fixes it

Go deeper

Documented occurrences

…and 76 more across the corpus — use search.

Honest provenance: generated on 2026-08-22 from AI-assisted analysis of the linked records. See how records are made.