orion-error-engineering

Guide structured Rust error boundaries using the orion-error crate.

10|Updated Apr 13, 2026
One-click install
npx skills add https://github.com/galaxio-labs/orion-skills --skill orion-error-engineering
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: orion-error-engineering
Source: https://github.com/galaxio-labs/orion-skills/tree/main/skills/orion-error-engineering
Command: npx skills add https://github.com/galaxio-labs/orion-skills --skill orion-error-engineering

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps you migrate to and apply the orion-error Rust crate correctly so your services produce consistent, structured, and interoperable error boundaries instead of stale or legacy error-handling patterns.

Core Features & Use Cases

  • Domain reason modeling and governance: choose stable identities for business variants and keep shared infrastructure categories transparent over UnifiedReason.
  • Correct API selection for conversions and sources: decide between to_err(), source_err(), source_raw_err(), with_source(), conv_err(), and interop APIs based on the upstream error type and boundary semantics.
  • Diagnostics-to-protocol workflow: use report(), exposure(), and JSON/protocol rendering paths to produce correct machine and human-facing error representations while keeping payloads out of reason values.
  • Migration guidance and review heuristics: detect and replace removed/legacy APIs (owe_*, err_wrap, with, etc.) and update old 0.6/0.7-era examples to current 0.8.x practices.

Quick Start

Use this skill to review an existing Rust codebase that uses legacy orion-error error APIs and update it to structured 0.8.x patterns: migrate a failing service that still calls owe_* and map_err wrappers into source_err()/source_raw_err() with correct identities and protocol rendering.

Frequently Asked Questions about orion-error-engineering

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I migrate legacy orion-error APIs to structured Rust error handling?

Structured error handling in Rust uses orion-error to model domain reasons via OrionError and govern identities using ErrorIdentity.code. This approach separates error payloads from reason values, producing consistent protocol outputs for APIs, logs, and interop.

When should I use source_err versus source_raw_err for Rust error conversions?

Use source_err and source_raw_err to attach upstream errors based on boundary semantics and the upstream error type. Selecting the correct conversion function ensures proper source attachment and maintains consistent structured error boundaries across your Rust APIs.

How do I render structured Rust errors into machine-readable protocol outputs?

Render structured Rust errors into protocol outputs using the report(), exposure(), and JSON rendering paths. This diagnostics-to-protocol workflow produces correct machine and human-facing representations while keeping payloads out of the reason values entirely.

Does orion-error support standard Rust error interop with as_std and into_std?

Yes, orion-error supports standard Rust error interop using as_std and into_std APIs. These functions allow seamless conversion between structured OrionError boundaries and standard Rust error types for cross-library compatibility.

What are the limitations of using conv_err for Rust error boundary conversions?

The conv_err function requires careful upstream error type matching and correct boundary semantics. Limitations arise when reason modeling lacks proper ErrorIdentity.code governance or when context, fields, and meta are misapplied, leading to inconsistent protocol rendering.