What causes "Operation cancelled.." in BoundaryML/baml?

Check whether the surrounding task/request was deliberately cancelled (timeout, abort, disconnect) and address that cause

BoundaryML/baml · warning

Operation cancelled..

Error message

Operation cancelled..

What it means

A traced function's future was cancelled before completing (the tokio select on cancellation fired). The runtime still emits a function_end trace event, then returns an anyhow error 'Operation cancelled..' to signal the caller that the work was aborted mid-flight.

Source

Thrown at engine/baml-runtime/src/lib.rs:380

            // Only execute drop logic if we have an error (early return case)
            let result: Result<FunctionResult> = if let Some(error) = self.error_result.take() {
                Err(error)
            } else {
                // Dropped without explicit finish - likely due to cancellation/shutdown
                // Instead of returning an error, emit a function end event for cancellation.
                {
                    let function_end_event = TraceEvent::new_function_end(
                        self.call_id_stack.clone(),
                        Err(BamlError::External {
                            message: "Operation cancelled".into(),
                        }),
                        function_type.clone(),
                    );
                    BAML_TRACER
                        .lock()
                        .unwrap()
                        .put(Arc::new(function_end_event));
                    Err(anyhow::anyhow!("Operation cancelled.."))
                }
            };

            // Emit TraceEvent::new_function_end for the error case
            let trace_event = TraceEvent::new_function_end(
                self.call_id_stack.clone(),
                Err(result.as_ref().err().unwrap().to_baml_error()),
                function_type.clone(),
            );
            BAML_TRACER.lock().unwrap().put(Arc::new(trace_event));

            // Finish the baml call
            #[cfg(not(target_arch = "wasm32"))]
            {
                match self
                    .tracer_wrapper
                    .get_or_create_tracer(&self.env_vars)
                    .finish_baml_call(call, self.ctx, &result)

View on GitHub (pinned to bd85ce9dee)

Solutions

Check whether the surrounding task/request was deliberately cancelled (timeout, abort, disconnect) and address that cause
Increase timeouts or move long LLM calls off paths that get aborted quickly
Handle this error as an expected cancellation in the caller rather than retrying blindly
If cancellation is unintentional, avoid dropping the JoinHandle/future prematurely and use structured cancellation

Defensive patterns

Strategy: retry

Try / catch

match result {
    Err(e) if e.to_string().contains("Operation cancelled") => {
        // expected cancellation: cleanup, optionally retry
    }
    Err(e) => return Err(e),
    Ok(v) => v,
}

Prevention

Set generous timeouts on tasks wrapping BAML calls
Avoid dropping JoinHandles of in-flight LLM calls
Handle client disconnects explicitly before aborting tasks
Treat cancellation errors as control flow, not failures

When it happens

Trigger: Dropping/cancelling the future running a traced LLM function: task abort via tokio::select! on another branch, client disconnect, timeout, or a JoinHandle being dropped while a function call is in flight.

Common situations: HTTP request timeouts in web servers, user-initiated aborts (AbortController/reqwest cancellation), shutting down workers while BAML calls are pending, race conditions in streaming responses.

Related errors

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/98e2602796300c4d. Report an issue: GitHub.