How do you handle errors and retries in LangChain4j?

LangChain4j itself does not provide a built-in retry framework — it intentionally delegates retry logic to the infrastructure layer. However, there are several natural integration points for error handling depending on your deployment context.

Rate limit handling (HTTP 429) — Most provider implementations in LangChain4j throw a dev.langchain4j.exception.RateLimitException when the LLM provider returns a 429. You handle this at the call site or through Spring's @Retryable mechanism:

// Using Spring Retry with @Retryable
@Service
class AiService {
    private final ChatAssistant assistant;

    @Retryable(
        retryFor = RateLimitException.class,
        maxAttempts = 3,
        backoff = @Backoff(delay = 2000, multiplier = 2)
    )
    public String chat(String userId, String message) {
        return assistant.chat(userId, message);
    }

    @Recover
    public String fallback(RateLimitException ex, String userId, String message) {
        return "Service is temporarily busy. Please try again in a moment.";
    }
}

Timeout handling — Configure timeouts directly on the ChatLanguageModel builder:

OpenAiChatModel model = OpenAiChatModel.builder()
    .apiKey(apiKey)
    .timeout(Duration.ofSeconds(30))
    .maxRetries(2) // some providers support built-in retries in the client
    .build();

The OpenAI and some other provider clients support a maxRetries parameter that enables automatic retries with exponential backoff inside the HTTP client before the exception propagates to your code. For structured error handling across all exceptions, wrapping the AI Services call in a try-catch and mapping to application-specific error responses is standard practice. Resilience4j's circuit breaker is another option for preventing cascading failures when an LLM provider is degraded.