Skip to Content

What does the error.type attribute mean in Rius?

In Rius, error.type is a span attribute that holds a low-cardinality error class, such as anthropic.NotFoundError or tool_error, on any span that ended in an error. It names the kind of failure, not the message or the stack. Set it on the failed span and pair it with the standard exception event when you want the details.

How it works

  • What the key holds. The OpenTelemetry conventions define error.type as a stable string that “describes a class of error the operation ended with”. It SHOULD be predictable and low-cardinality, an exception type SHOULD be recorded by its canonical class name, and it SHOULD NOT be set when the operation succeeded. Its registry entry links that definition. Two examples are anthropic.NotFoundError, the class of a provider error, and tool_error, which the Rius SDKs set on an MCP tools/call whose result reports a failure. Keep free-text messages out of the key.
  • Which spans carry it. Any span that ended in an error. It is not tied to one kind of span, so a model call, a tool call, an agent step or a retrieval can each carry it.
  • What goes beside it. The standard OpenTelemetry exception event, the one you record with record_exception, also surfaces in error analysis. The two work together: error.type classifies the failure, and the event carries the exception detail.
  • Coding agents. The Rius plugin for coding agents sends error types even in structure-only mode, the mode that never sends prompts, replies, file contents or command output. Enabling a folder with /rius:enable-here in Claude Code gives you the span tree, models, tokens, cost, timing, tool names and error types.

The key is one of the attributes Rius reads from spans. The span attribute reference lists it with the agent, tool and retrieval attributes.

Set it up

  1. Pick a small set of error classes. Use the exception class name for provider and library errors, as in anthropic.NotFoundError. Use a fixed label such as tool_error for failures you raise yourself. Reuse the same labels across your agents so the values stay few and comparable.
  2. Set error.type on the span that failed. Set it only on spans that ended in an error. Set it on the failing span itself, for example the tool call that raised, not only on a parent that reports the result.
  3. Record the exception too. Call record_exception on the span, so the standard exception event sits beside the class and shows up in error analysis.
  4. Send the spans to Rius. If you emit spans from a vanilla OpenTelemetry SDK or a collector rather than the Rius SDKs, post OTLP over HTTP to the ingest endpoint with your API key in an Authorization header:
POST https://ingest.eu.console.rius-glassflow.com/v1/traces Authorization: Bearer <your API key> Content-Type: application/x-protobuf
  1. Check the result. Open the trace in Rius and look at the span that failed. For senders other than the Rius SDKs, Trace LLM calls with OpenTelemetry walks through the full setup.

What you get

  • A short, consistent label on every failed span, so you can tell a provider error from a failed tool call without reading the whole trace.
  • Error classes that stay readable because you keep them low-cardinality: a handful of repeating values rather than a new string for every failure.
  • Exception detail on the same span, through the exception event, which surfaces in error analysis.
  • Error types in coding-agent traces even when a developer shares structure only, because the plugin sends them without prompts, replies or command output.
  • The same key whether the span comes from a Rius SDK, a vanilla OpenTelemetry SDK or a collector pipeline, since Rius reads it from the span either way.

When something else fits

  • If you need the failure message or stack, record the exception event. error.type is only the class.
  • If you need to know which tool failed, read gen_ai.tool.name on the execute_tool span, which holds the tool’s own name. error.type says what kind of failure it was, not where.
  • If you want a notification when errors build up, set up a custom alert on error rate or errors. The attribute labels failures, and alerts are what watch for them.

Still stuck? Get help

Last updated on