pinpoint-apm/pinpoint · error · Error

Request failed with status ${response.status}. An error occu

Error message

Request failed with status ${response.status}. An error occurred while fetching the data.

What it means

In Pinpoint's web-frontend reactQueryHelper, parseResponseError is called for non-OK fetch responses and first attempts response.json(). If the response body is not valid JSON (json() throws), the helper throws a generic Error including the HTTP status: 'Request failed with status <status>. An error occurred while fetching the data.' This is the fallback path when the server did not return a parseable JSON error body.

Source

Thrown at web-frontend/src/main/v3/packages/ui/src/hooks/api/reactQueryHelper.tsx:44

  }
}

function isServerErrorResponse(body: unknown): body is ErrorResponse {
  const o = body as Record<string, unknown>;
  return (
    o != null &&
    typeof o === 'object' &&
    typeof o.status === 'number' &&
    (typeof o.detail === 'string' || typeof o.title === 'string')
  );
}

export async function parseResponseError(response: Response): Promise<never> {
  let body: unknown;
  try {
    body = await response.json();
  } catch {
    throw new Error(
      `Request failed with status ${response.status}. An error occurred while fetching the data.`,
    );
  }

  if (isServerErrorResponse(body)) {
    const serverError = body;
    const err = new Error(
      serverError.detail || serverError.title || 'An error occurred while fetching the data.',
    ) as Error & ErrorResponse;
    Object.assign(err, serverError);
    err.message = serverError.detail || serverError.title || err.message;
    throw err;
  }

  const detail =
    typeof (body as Record<string, unknown>)?.detail === 'string'
      ? (body as Record<string, unknown>).detail
      : typeof (body as Record<string, unknown>)?.message === 'string'

View on GitHub (pinned to 744c3d3075)

Solutions

Check the backend/Pinpoint web server is running and reachable — HTML gateway error pages are the usual cause.
Inspect response.status: 401/403 means re-authenticate, 5xx means server-side failure.
Check proxies/reverse proxies (nginx, gateway) are not intercepting the request with non-JSON error pages.
Server-side: ensure error handlers return a JSON body so the isServerErrorResponse branch is used instead.
Client-side: wrap calls to react-query hooks in try/catch and surface error.message plus response status to users.

Example fix

// before
if (!res.ok) return parseResponseError(res); // opaque error when body isn't JSON
// after
if (!res.ok) {
  const ct = res.headers.get('content-type') || '';
  if (!ct.includes('application/json')) {
    console.error('Non-JSON error response', res.status, await res.text());
  }
  return parseResponseError(res);
}

Defensive patterns

Strategy: try-catch

Validate before calling

if (!response.ok && !(response.headers.get('content-type') || '').includes('application/json')) {
  throw new Error(`Non-JSON error response (${response.status}); server or proxy likely misconfigured`);
}

Type guard

const isJsonResponse = async (res: Response): Promise<boolean> =>
  (res.headers.get('content-type') || '').includes('application/json') &&
  (await res.clone().text()).trim().startsWith('{');

Try / catch

try {
  const data = await queryFn();
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Request failed with status')) {
    const status = Number(e.message.match(/status (\d+)/)?.[1] ?? 0);
    if (status === 401 || status === 403) redirectToLogin();
    else if (status >= 500) showError('Server unavailable, please retry later');
    else showError(e.message);
  } else throw e;
}

Prevention

Monitor backend health; HTML 502/503 proxy pages are the usual source of unparseable bodies.
Handle 401/403 centrally (e.g. auth redirect) before generic error parsing.
Ensure server error handlers always emit JSON with a proper Content-Type.
Log response.text() for non-JSON error responses to aid debugging.
Add react-query onError handlers that distinguish network/auth/server failures.

When it happens

Trigger: A fetch wrapper calls parseResponseError on a non-2xx response whose body is empty, HTML (e.g. a proxy/gateway error page), plain text, or otherwise unparseable JSON.

Common situations: Backend down and a load balancer returns an HTML 502/503 page; session expired and server returns an HTML login redirect; gateway truncates the body; wrong Content-Type causes json() to fail even when a body exists.

Understand the failure class

Background: "Invalid JSON response" and "Failed to parse response" errors: when an API answers 200 but the body isn't the JSON your library expected — this error's family across 28 libraries.

Related errors

AI-assisted analysis of pinpoint-apm/pinpoint@744c3d3075 (2026-09-07). Data as JSON: /api/errors/983698ca1452377d. Report an issue: GitHub.