milvus-io/milvus · error
Failed to request errors
Error message
Failed to request errors
What it means
Thrown by the WebUI when POSTing a 'show_errors' command to /_telemetry/commands targeting a specific client fails with a non-2xx, non-401 status. The telemetry command channel refused the request: usually the target client_id is unknown to the server (it has never heartbeat-ed or has been evicted), or the request payload failed server-side validation.
Source
Thrown at internal/http/webui/telemetry.html:2006
headers: {
'Content-Type': 'application/json',
...(authToken ? { 'Authorization': authToken } : {})
},
body: JSON.stringify({
command_type: 'show_errors',
target_client_id: clientId,
payload: '{"limit": 100}',
ttl_seconds: 300 // 5 minutes TTL
})
});
if (resp.status === 401) {
logout();
return;
}
if (!resp.ok) {
throw new Error('Failed to request errors');
}
document.getElementById('errorModalContent').innerHTML = `
<div class="empty-state" style="padding: 20px;">
<p>Error request sent to client.</p>
<p style="font-size: 13px; color: var(--gray-500); margin-top: 8px;">
The show_errors command has been pushed to the client.
Errors will be included in the client's next heartbeat response
and can be viewed in the server logs.
</p>
<p style="font-size: 12px; color: var(--gray-400); margin-top: 12px;">
Note: Client errors are collected locally on each client and sent to the server
when the show_errors command is received. Check the Milvus server logs for the error details.
</p>
</div>
`;
} catch (error) {
document.getElementById('errorModalContent').innerHTML = `View on GitHub (pinned to b43a76673a)
Solutions
- Refresh the client list and confirm the target client_id still appears with a recent heartbeat before re-sending.
- If the client is gone, wait for it to reconnect and heartbeat, then retry.
- Inspect the server response body (the code discards it) via browser devtools Network tab for the exact error string.
Example fix
// before
if (!resp.ok) {
throw new Error('Failed to request errors');
}
// after
if (!resp.ok) {
const err = await resp.json().catch(() => ({}));
throw new Error(err.error || `Failed to request errors (HTTP ${resp.status})`);
} Defensive patterns
Strategy: try-catch
Validate before calling
// verify the client is still registered before sending the command
const list = await (await fetch(`${API_BASE}/_telemetry/clients`, { headers: { 'Authorization': authToken } })).json();
const alive = (list.clients || []).some(c => c.client_id === clientId && Date.now() - c.last_heartbeat_ms < 60000);
if (!alive) { showToast('Client is not connected; cannot request errors', 'warning'); return; } Try / catch
try {
const resp = await fetch(url, { method: 'POST', headers, body: JSON.stringify(payload) });
if (resp.status === 401) { logout(); return; }
if (!resp.ok) {
const err = await resp.json().catch(() => ({}));
throw new Error(err.error || `Failed to request errors (HTTP ${resp.status})`);
}
} catch (e) { showToast(e.message, 'error'); } Prevention
- Check the client's last heartbeat before issuing client-scoped commands.
- Always parse and surface the server error body; it names the actual rejection reason.
- Handle 401 uniformly at the top of every telemetry fetch helper.
When it happens
Trigger: Clicking 'Show errors' for a client that went offline and was removed from the server's client registry; client_id typo/encoding issue; command queue write failure (500) on the server.
Common situations: Client list is stale in the browser (opened before clients disconnected); short client eviction timeout so entries vanish between listing and command submission; Milvus restart clearing in-memory telemetry state.
Related errors
- Failed to fetch errors
- Server error
- Failed to delete command
- HTTP ${response.status}
- HTTP error: ${resp.status}
AI-assisted analysis of milvus-io/milvus@b43a76673a (2026-08-15).
Data as JSON: /api/errors/4ce5813ee44e29ff.
Report an issue: GitHub.