Skip to main content
Prerequisites: The Requirements System, Quick Start complete, pip install mellea. Mellea programs encounter two categories of failure: expected failures (IVR exhaustion, precondition violations) that are part of normal operation, and unexpected errors (backend connectivity, parse failures) that indicate configuration or implementation problems.

Expected failures

IVR loop exhaustion: SamplingResult.success = False

When instruct() is called with return_sampling_results=True and the IVR loop exhausts its budget without satisfying all requirements, SamplingResult.success is False. This is not a Python exception — it is a normal return value that your code should handle.
Common fallback patterns when success is False:
  • Use the best attempt anywayresult.sample_generations[0].value gives the first (often the best) generation, even if requirements were not fully satisfied.
  • Lower the bar — retry with reduced requirements or a higher loop_budget.
  • Return an error indicator — tell the caller the operation could not be completed to spec, and let it decide.
  • Log and alert — if this should rarely fail, log the attempts and notify.

Inspecting failure reasons

SamplingResult.sample_validations gives per-attempt validation details. Use them to understand which requirements are failing and why:
A requirement that fails on every attempt usually indicates one of:
  • The model cannot satisfy this constraint with the current prompt and model.
  • The validation_fn has a bug (returns False unconditionally or has a logic error).
  • The requirement is genuinely contradictory with the instruction.

Precondition failures: PreconditionException

When precondition_requirements are attached to a @generative call, Mellea validates the inputs before calling the model. If any precondition fails, PreconditionException is raised immediately — no model call is made:
PreconditionException.validation is a list of ValidationResult objects for the requirements that failed. Each .reason field explains what was wrong. Use preconditions to:
  • Validate untrusted inputs before they reach the model
  • Enforce interface contracts between pipeline stages
  • Fail fast on inputs that are guaranteed to produce bad output

Unexpected errors

Backend connection errors

If Ollama is not running, or a cloud API key is invalid, the backend raises an exception on the first model call:
For production code, wrap session creation and the first call together:

Parse failures: ComponentParseError

When @generative or instruct(format=...) is used with a Pydantic model or Literal return type, Mellea parses the raw model output into the declared type. If parsing fails, a ComponentParseError is raised. This typically means the model produced output that does not conform to the schema. The IVR loop retries on parse failure automatically — ComponentParseError surfaces only if all retries are exhausted.
If ComponentParseError occurs in practice, check:
  • Whether the model is large enough to follow the output format instructions.
  • Whether the instruction and docstring are clear about the expected format.
  • Whether the backend supports constrained decoding for the return type.

Fallback and retry patterns

Fallback to a simpler call

If a structured call fails, fall back to a plain instruct():

Fallback to a different model

For calls that require higher capability, escalate to a stronger model on failure:
This is the basis of the SOFAI (System 1 / System 2) pattern — fast model first, strong model only when needed. Mellea provides SOFAISamplingStrategy as a built-in implementation. See Inference-Time Scaling.

Logging failures

Use Python’s standard logging module to record failures alongside generation details:
For structured telemetry across all calls, see Telemetry.
See also: The Requirements System | Write Custom Verifiers