Module effect 

Effect system for error-as-effects pattern.

This module implements the “errors as effects” pattern where domain errors are first-class events that can be persisted, replayed, and affect downstream handlers.

Usage Guidelines

Effect at Boundaries, Result Internally

Internal code should use Result<T, E> for normal error handling. Effect<T> should only be used at system boundaries:

• Event handler outputs
• Persistence layer responses
• API response wrappers

// Internal: use Result
async fn fetch_notes(&self, id: ScopeId) -> Result<Vec<Note>, StorageError> {
    let rows = self.db.query(...).await?;
    Ok(rows)
}

// Boundary: wrap in Effect
pub async fn handle_request(&self, req: Request) -> Effect<Response> {
    match self.do_work(req).await {
        Ok(resp) => Effect::Ok(resp),
        Err(e) if e.is_transient() => Effect::Retry { ... },
        Err(e) => Effect::Err(ErrorEffect::from(e)),
    }
}

Key Distinction

• Domain errors: Persist, replay, affect downstream handlers
• Operational errors: Telemetry only, can sample/discard

Domain errors are part of the business logic and must be tracked. Operational errors are infrastructure concerns and can be handled separately.

Modules

duration_millis 🔒

Structs

DomainErrorContext

Domain error with event context for correlation and replay.

Enums

CompensationAction

Action to take for compensating a failed operation.

DomainError

Domain-level errors that affect business logic.

Effect

An effect represents the outcome of an operation.

ErrorEffect

An error effect that can be persisted and replayed.

ErrorKind

High-level error categorization for metrics and routing.

OperationalError

Operational errors that don’t affect business logic.

WaitCondition

Condition that a pending effect is waiting for.

Traits

ErrorClassifiable

Unified error classification for retry/intervention decisions across all error types.