mastra-ai/mastra · error · MastraError

OBSERVABILITY_STORAGE_LIST_TRACES_NOT_IMPLEMENTED

OBSERVABILITY_STORAGE_LIST_TRACES_NOT_IMPLEMENTED

Error message

This storage provider does not support listing traces

What it means

listTraces() retrieves traces with optional filtering (pagination, resource, attributes). The base class throws by default, so the error indicates the configured storage adapter implements no trace-listing capability. Used by trace listing UIs and the { spans, ...rest } aggregation paths.

Source

Thrown at packages/core/src/storage/domains/observability/base.ts:322

   * Batch-fetches spans by spanId within a single trace. Used by the
   * optimized {@link getBranch} path to fetch only the spans that belong to
   * the requested branch (after walking the lightweight structure to identify
   * them) instead of pulling the entire trace.
   */
  async getSpans(_args: GetSpansArgs): Promise<GetSpansResponse> {
    throw new MastraError({
      id: 'OBSERVABILITY_STORAGE_GET_SPANS_NOT_IMPLEMENTED',
      domain: ErrorDomain.MASTRA_OBSERVABILITY,
      category: ErrorCategory.SYSTEM,
      text: 'This storage provider does not support batch-fetching spans',
    });
  }

  /**
   * Retrieves a list of traces with optional filtering.
   */
  async listTraces(_args: ListTracesArgs): Promise<ListTracesResponse> {
    throw new MastraError({
      id: 'OBSERVABILITY_STORAGE_LIST_TRACES_NOT_IMPLEMENTED',
      domain: ErrorDomain.MASTRA_OBSERVABILITY,
      category: ErrorCategory.SYSTEM,
      text: 'This storage provider does not support listing traces',
    });
  }

  /**
   * Retrieves a lightweight list of traces with optional filtering.
   *
   * Defaults to {@link listTraces} with each row projected down, so every backend
   * serves the same response shape whether or not it has a dedicated implementation.
   * Backends that can push the projection into the query should override this --
   * that is what actually keeps the blob columns off the read path -- but the
   * fallback stays correct, just not cheaper than `listTraces`.
   */
  async listTracesLight(args: ListTracesArgs): Promise<ListTracesLightResponse> {
    const { spans, ...rest } = await this.listTraces(args);

View on GitHub (pinned to 75dd419e61)

Solutions

1. Switch to a storage adapter that overrides listTraces (libsql, PostgreSQL, upstash, etc.).
2. Implement listTraces() in your custom adapter (paginated SELECT over root/anchor spans).
3. If traces are exported to a dedicated backend (e.g. a telemetry vendor), query that system instead of Mastra storage.
4. Guard with a capability check and render an empty/disabled traces view instead of throwing.

const supportsListTraces = obs.listTraces !== ObservabilityStorage.prototype.listTraces;

function supportsListTraces(o: { listTraces: unknown }): o is { listTraces: (a: any) => Promise<any> } {
  return o.listTraces !== (ObservabilityStorage.prototype as any).listTraces;
}

try {
  return await obs.listTraces(args);
} catch (e) {
  if ((e as MastraError).id === 'OBSERVABILITY_STORAGE_LIST_TRACES_NOT_IMPLEMENTED') {
    return { traces: [], total: 0 };
  }
  throw e;
}

When it happens

Trigger: Calling storage.getObservability().listTraces(args) — e.g. the traces list page, a paginated query, or code aggregating spans plus trace metadata — on an adapter that kept the base default.

Common situations: Using a storage backend chosen only for workflow/memory persistence that lacks observability reads; custom test doubles for storage; adapters older than the observability read API.

Related errors

• OBSERVABILITY_STORAGE_UPDATE_SPAN_NOT_IMPLEMENTED
• OBSERVABILITY_STORAGE_GET_SPAN_NOT_IMPLEMENTED
• OBSERVABILITY_STORAGE_GET_ROOT_SPAN_NOT_IMPLEMENTED
• OBSERVABILITY_STORAGE_GET_TRACE_NOT_IMPLEMENTED
• OBSERVABILITY_STORAGE_GET_STRUCTURE_NOT_IMPLEMENTED

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/2575c8c7f8a2ed5c. Report an issue: GitHub.