Module error 

Structured error envelope shared by core and the SDK.

This is the wire-level slice of the akribes-core::error module: the ErrorKind / ErrorCode enums plus their pure-data impls (as_wire, from_wire, kind, default_user_message, suggested_action, is_transient, is_server_error, is_user_actionable, base_backoff_ms), the ErrorSource / ErrorDetail envelopes, the SuggestedAction tag, and the ErrorCode::parse_retry_after_ms retry-after hint parser.

Functions that bring in heavier deps (regex-backed sanitize_error and ErrorKind::classify, the tokio-backed CancelTracker / CancelReason, the regex-backed ErrorCode::classify_provider_error) stay in akribes_core::error so the types crate keeps its dependency surface to serde, serde_json, thiserror, httpdate, and tracing.

Structs

ErrorDetail

Structured failure detail attached to a crate::value::Value::FatalError and to every EngineEvent::Error. Replaces the previous (message, kind) shape with a richer envelope so SDKs can decide what to do, users get actionable text, and developers get structured fields for OTel/logs.

ErrorSource

Where in the workflow an error originated. Every field is optional — fill what you know, leave the rest. SDKs render whichever fields are present; downstream tools (logs, OTel) read them as structured attributes for filtering/aggregation.

Enums

ErrorCode

Stable, fine-grained error identifier. Each code maps to exactly one ErrorKind and carries a default user-facing message. Wire form: AKRIBES-E-<UPPER-KEBAB> (e.g. AKRIBES-E-PROVIDER-RATE-LIMIT).

ErrorKind

Coarse error category. Use ErrorCode for the finer-grained, stable identifier that consumers should branch on; ErrorKind is the rollup every code belongs to (so a UI can show one bucket, an SDK can decide “is this retryable” without enumerating every code).

SuggestedAction

What the client/user/runner should do in response. Derived from ErrorKind (see ErrorKind::suggested_action) so consumers don’t have to maintain their own switch statement.