openzipkin/zipkin · error · Error
Failed to archive the trace
Error message
Failed to archive the trace
What it means
Thrown in zipkin-lens's HeaderMenu archive flow when the POST of the annotated trace JSON to the archive endpoint does not yield an acceptable status. Note the guard is written as !response.ok || (status !== 202 && status === 200): any HTTP 200 (ok) response is rejected because the code demands 202 Accepted, so an archive backend that answers 200 both works and still surfaces this error — a client-side condition bug on top of genuine failures.
Source
Thrown at zipkin-lens/src/components/TracePage/Header/HeaderMenu.tsx:94
}
}
return json;
})
.then((json) => {
return fetch(archivePostUrl, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify(json),
});
})
.then((response) => {
if (
!response.ok ||
(response.status !== 202 && response.status === 200)
) {
throw new Error('Failed to archive the trace');
}
if (archiveUrl) {
dispatch(
setAlert({
message: `Archive successful! This trace is now accessible at ${archiveUrl}`,
severity: 'success',
}),
);
} else {
dispatch(
setAlert({
message: `Archive successful!`,
severity: 'success',
}),
);
}
})
.catch(() => {View on GitHub (pinned to 878ce2a1fa)
Solutions
- If you control the archive endpoint, return 202 Accepted for successful archival so the existing check passes
- Check the browser network tab for the POST's real status: 4xx/5xx means config/auth/CORS — fix URL, headers, or proxy
- If the endpoint legitimately returns 200, patch the condition to accept success statuses: !response.ok alone (drop the (status !== 202 && status === 200) clause, or explicitly allow 200 and 202)
Example fix
// before
if (!response.ok || (response.status !== 202 && response.status === 200)) {
throw new Error('Failed to archive the trace');
}
// after
if (!response.ok) {
throw new Error(`Failed to archive the trace (HTTP ${response.status})`);
} Defensive patterns
Strategy: try-catch
Validate before calling
// pre-flight the archive endpoint configuration before the archive attempt
if (!archiveUrl) {
throw new Error('Archive endpoint is not configured');
} Try / catch
.then((response) => {
if (!response.ok) {
// include the real status; accept 200 and 202 as success
throw new Error(`Failed to archive the trace (HTTP ${response.status})`);
}
})
.catch((err) => {
dispatch(setAlert({ message: err.message, severity: 'error' }));
}); Prevention
- Make the archive service return 202 Accepted to match the client's expectation
- Accept both 200 and 202 in the client check (or rely on response.ok alone)
- Verify archive endpoint URL, auth headers, and CORS settings before enabling the archive button
- Include the HTTP status in thrown errors to speed up diagnosis
When it happens
Trigger: POSTing to the configured archive endpoint when it returns 4xx/5xx (misconfigured URL, auth required, CORS blocked); the archive server responding 200 OK instead of 202 Accepted, which this code incorrectly treats as failure; network error before the response arrives.
Common situations: Self-hosted archive service (e.g. a custom trace-archive API) that returns 200 rather than 202; archiveUrl env/config pointing at the wrong path; reverse proxy stripping CORS headers so the browser flags the response; auth token missing and endpoint answering 401.
Related errors
AI-assisted analysis of openzipkin/zipkin@878ce2a1fa (2026-08-14).
Data as JSON: /api/errors/2550972f93c37cec.
Report an issue: GitHub.