OnErrorPolicy

Trait OnErrorPolicy 

Source
pub trait OnErrorPolicy:
    Send
    + Sync
    + Debug {
    // Required methods
    fn create_child(&self) -> Arc<dyn OnErrorPolicy>;
    fn create_context(&self) -> Option<Box<dyn Any + Send + 'static>>;
    fn on_error(
        &self,
        error: &Error,
        context: &mut OnErrorContext,
    ) -> ErrorResponse;

    // Provided methods
    fn allow_continuation(
        &self,
        _error: &Error,
        _context: &OnErrorContext,
    ) -> bool { ... }
    fn should_reschedule(
        &self,
        _error: &Error,
        _context: &OnErrorContext,
    ) -> bool { ... }
}
Expand description

Error handling policy trait for task failures

Policies define how the TaskTracker responds to task failures. They can be stateless (like LogOnlyPolicy) or maintain per-task state (like ThresholdCancelPolicy with per-task failure counters).

Required Methods§

Source

fn create_child(&self) -> Arc<dyn OnErrorPolicy>

Create a child policy for a child tracker

This allows policies to maintain hierarchical relationships, such as child cancellation tokens or shared circuit breaker state.

Source

fn create_context(&self) -> Option<Box<dyn Any + Send + 'static>>

Create per-task context state (None if policy is stateless)

This method is called once per task when the first error occurs. Stateless policies should return None to avoid unnecessary heap allocations. Stateful policies should return Some(Box::new(initial_state)).

§Returns
  • None - Policy doesn’t need per-task state (no heap allocation)
  • Some(state) - Initial state for this task (heap allocated when needed)
Source

fn on_error(&self, error: &Error, context: &mut OnErrorContext) -> ErrorResponse

Handle a task failure and return the desired response

§Arguments
  • error - The error that occurred
  • context - Mutable context with attempt count, task info, and optional state
§Returns

ErrorResponse indicating how the TaskTracker should handle this failure

Provided Methods§

Source

fn allow_continuation(&self, _error: &Error, _context: &OnErrorContext) -> bool

Should continuations be allowed for this error?

This method is called before checking if a task provided a continuation to determine whether the policy allows continuation-based retries at all. If this returns false, any FailedWithContinuation will be ignored and the error will be handled through the normal policy response.

§Arguments
  • error - The error that occurred
  • context - Per-task context with attempt count and state
§Returns
  • true - Allow continuations, check for FailedWithContinuation (default)
  • false - Reject continuations, handle through normal policy response
Source

fn should_reschedule(&self, _error: &Error, _context: &OnErrorContext) -> bool

Should this continuation be rescheduled through the scheduler?

This method is called when a continuation is about to be executed to determine whether it should go through the scheduler’s acquisition process again or execute immediately with the current execution permission.

What this means:

  • Don’t reschedule (false): Execute continuation immediately with current permission
  • Reschedule (true): Release current permission, go through scheduler again

Rescheduling means the continuation will be subject to the scheduler’s policies again (rate limiting, concurrency limits, backoff delays, etc.).

§Arguments
  • error - The error that triggered this retry decision
  • context - Per-task context with attempt count and state
§Returns
  • false - Execute continuation immediately (default, efficient)
  • true - Reschedule through scheduler (for delays, rate limiting, backoff)

Implementors§