iflytek/astron-agent · error · Error

response.data.message || response.data.desc

Error message

response.data.message || response.data.desc

What it means

getTraceList calls GET /trace/getTrace and throws Error(response.data.message || response.data.desc) when the business code is not 0; the catch block additionally shows an antd message toast and rethrows. The thrown text is the backend's error message/description for a failed trace-list query.

Solutions

1. Check the trace service health and its backing storage (ES/Jaeger) in the target deployment; the frontend toast shows the backend's raw reason.
2. Validate params before calling: startTime < endTime, valid ISO strings, sane pagination limits.
3. Verify space-id/enterprise-id headers are attached (axios interceptor) for the current tenant.
4. Handle the rethrown error upstream so the list shows an empty/error state instead of an unhandled rejection, and avoid double-toasting since getTraceList already calls message.error.

Example fix

// before
const traces = await getTraceList(params);
setTraces(traces);
// after
try {
  const traces = await getTraceList(params);
  setTraces(traces ?? []);
} catch {
  setTraces([]); // message already shown by getTraceList
  setErrorState(true);
}

// validate params before requesting
if (!params.startTime || !params.endTime || params.startTime >= params.endTime) {
  message.warning('请选择有效的时间范围');
  return;
}

function hasTraceParams(p: any): p is { startTime: string; endTime: string } {
  return !!p && typeof p.startTime === 'string' && typeof p.endTime === 'string' && p.startTime < p.endTime;
}

try {
  const list = await getTraceList(params);
  setTraces(list ?? []);
} catch {
  setTraces([]); // toast already shown inside getTraceList
  setErrorState(true);
}

When it happens

Trigger: The trace service returns code !== 0 — trace backend unreachable/down, invalid query params (bad time range, oversized limit), tenant/space headers missing or unauthorized, or the trace storage (e.g. Elasticsearch) query failing server-side.

Common situations: Observability stack not deployed in self-hosted environments so /trace/getTrace 500s; date-range parameters formatted incorrectly; user lacks space permissions for the queried traces; tracing feature flag disabled server-side.

Related errors

• response.data.message
• PARAMETER_ERROR
• RESPONSE_FAILED
• OPEN_AI_API_ERROR
• PARAM_ERROR

AI-assisted analysis of iflytek/astron-agent@5e758547a8 (2026-09-12). Data as JSON: /api/errors/00a0dd744b880939. Report an issue: GitHub.

Appendix: source

Thrown at console/frontend/src/services/trace.ts:51

  rawStatus?: Record<string, unknown>;
  usage?: WorkflowTraceUsage;
  input?: Record<string, unknown>;
  config?: Record<string, unknown>;
  output?: Record<string, unknown>;
  logs?: string[];
};

export type WorkflowTraceExecutionDetail = {
  execution: WorkflowTraceExecutionItem;
  nodes: WorkflowTraceNode[];
};

// TODO: trans fn use
export async function getTraceList(params: any) {
  try {
    const response: any = await http.get(`/trace/getTrace`, { params });
    if (response?.data.code !== 0) {
      throw new Error(response.data.message || response.data.desc);
    }
    return response.data.data;
  } catch (error: any) {
    message.error(error?.message ?? '获取trace日志失败');
    throw error;
  }
}

export const getTraceCount = async (params: {
  botId: string;
  startTime: string;
  endTime: string;
}) => {
  try {
    const response: any = await http.get(`/trace/count`, { params });

    if (response?.data.code !== 0) {
      throw new Error(response.data.message || response.data.desc);

View on GitHub (pinned to 5e758547a8)