A user-facing fallback keeps an AI interface usable when generation fails, returns nothing, reaches a limit, or triggers a provider-specific restriction. It combines clear error messaging with a recovery path such as retrying the request. section 8.2.1
Implement the fallback around the server action that invokes the model. Catch the error, classify it with an error tracker, convert the result into a stable user-facing message, and render that message as an assistant response. section 8.2.1
A production-oriented fallback should:
- Detect errors with instanceof checks or message-pattern matching. section 8.2.1
- Centralize provider-specific error types and messages in an AIErrorTracker. section 8.2.1
- Include a request ID so users and support workflows can identify the failed interaction. section 8.2.1
- Offer retry when the failure is recoverable, while MCP servers can also return predefined fallback responses for unavailable external APIs. section 8.2.1 section 12.8
Chat response fallback
A conversation action catches a provider error, calls AIErrorTracker.trackError with the provider, model, and input, then renders the resulting message in a ChatBubble with an optional Retry button.
Listing 8.2 Integrating error tracking into the application
import { AIErrorTracker } from '@/lib/error-tracking'; #1
export async function continueConversation(input, provider, model) {
...
} catch (error) {
const errorData =
await AIErrorTracker.trackError(error, { #2
provider,
model,
input,
});
const userError =
AIErrorTracker.createUserFacingError(errorData); #3
return {
id: userError.requestId,
role: 'assistant',
display: ( #4
<ChatBubble
role="error"
text={`${userError.message} (Request ID: ${userError.requestId})`}
className="mr-auto border-none error"
/>
),
};
}
Inspect the complete error-handling path from caught provider exception to rendered assistant-side fallback. section 8.2.1
