milvus-io/milvus · error

Failed to fetch errors

Error message

Failed to fetch errors

What it means

Thrown when POSTing the fetch-errors command (client-scope show_errors with ttl 300s) to /_telemetry/commands fails with non-2xx, non-401 status. Identical failure family to the other command pushes: target client unknown/evicted, payload rejected, or server 500. The server's error body overrides the literal message when parseable.

Source

Thrown at internal/http/webui/telemetry.html:2900

                        ...(authToken ? { 'Authorization': authToken } : {})
                    },
                    body: JSON.stringify({
                        command_type: 'show_errors',
                        target_client_id: clientId,
                        payload: JSON.stringify(payload),
                        ttl_seconds: 300,
                        persistent: false
                    })
                });

                if (resp.status === 401) {
                    logout();
                    return;
                }

                if (!resp.ok) {
                    const error = await resp.json();
                    throw new Error(error.error || 'Failed to fetch errors');
                }

                const result = await resp.json();

                // Refresh commands from server
                await loadServerCommands();

                // Start polling for the response
                pollForCommandReply(result.command_id, clientId, 'errors');

            } catch (error) {
                showToast('Error: ' + error.message, 'error');
                document.getElementById('errorsContent').innerHTML = `<p style="color: var(--danger);">Error: ${escapeHtml(error.message)}</p>`;
            }
        }

        // Poll for command reply
        async function pollForCommandReply(commandId, clientId, type, aggregate) {

View on GitHub (pinned to b43a76673a)

Solutions

  1. Refresh the client list and retry against a client with a current heartbeat.
  2. Read the toast / devtools response body for the exact server-side reason.
  3. If persistent, check proxy logs around POST /_telemetry/commands for a 500 stack trace.
Defensive patterns

Strategy: try-catch

Validate before calling

if (!clientId) { showToast('No client selected', 'error'); return; }

Try / catch

try {
  const resp = await fetch(url, { method: 'POST', headers, body });
  if (resp.status === 401) { logout(); return; }
  if (resp.status === 404) { showToast('Client no longer registered; refresh the list', 'warning'); return; }
  if (!resp.ok) {
    const error = await resp.json().catch(() => ({}));
    throw new Error(error.error || `Failed to fetch errors (HTTP ${resp.status})`);
  }
} catch (e) { showToast(e.message, 'error'); }

Prevention

When it happens

Trigger: Clicking 'Fetch errors' on a client row for a client that disconnected and was evicted from the registry; malformed payload; command-store write failure.

Common situations: Client list stale in a long-open tab; ephemeral clients (CLI tools, short-lived SDK sessions) vanishing between list and command; Milvus restart.

Related errors


AI-assisted analysis of milvus-io/milvus@b43a76673a (2026-08-15). Data as JSON: /api/errors/d27de3846a31048b. Report an issue: GitHub.