DEV Community: Matheus Lima

How to Stop LLM Hallucinations from Crashing Your React UI (Fixing AI_JSONParseError)

Matheus Lima — Thu, 02 Apr 2026 01:03:54 +0000

Building Generative UIs with tools like the Vercel AI SDK is incredibly powerful until it suddenly isn't.

ou’ve set up your tool calls, your streaming is incredibly fast, and it works flawlessly 99% of the time. But LLMs are inherently non-deterministic. Eventually, the model will drop a quote mark in the middle of a JSON stream, or decide to wrap its raw output inside a markdown block (json).

When that happens, your application doesn't just show a typo. It throws a synchronous parsing error. And in React, an unhandled error means one thing: The White Screen of Death (WSOD).

If you look at the Vercel AI SDK GitHub repository, you'll see developers fighting this in the trenches:

Issue #13514: Tool streaming causes malformed JSON.
Issue #4906: The LLM randomly outputs Markdown blocks instead of pure objects, crashing the preflight parsing.
Issue #1167: RSC stream aborts completely unmount the React tree.

Let's look at why standard React tools fail here, and how to elegantly quarantine these hallucinations.

The Trap of Standard Error Boundaries

When a standard React component throws an error, the official advice is to wrap it in an <ErrorBoundary>. But Generative UI is different.

If you are building an AI Chat interface, the tool component (let's say, a financial chart generated by the LLM) is a child of the message list. If the LLM hallucinates the schema (e.g., returns a string instead of an array) and your chart component tries to .map() over it, it crashes.

If you rely on a generic Error Boundary higher up in your tree, React unmounts the entire chat history to show the fallback UI. Your user just lost their entire 20-minute context because the AI forgot a comma. That is unacceptable UX.

The Ugly Fix

To prevent this, developers end up writing massive, defensive try/catch blocks inside every single component, or attempting to write regex-based "JSON cleaners" to sanitize strings mid-stream. It pollutes your codebase with error-handling logic that obscures the actual business logic.

The Elegant Fix: Quarantining Generative UI

We need a surgical approach: a boundary specifically designed for the unpredictable nature of AI payloads. That's why I built <AIBoundary /> as part of the CogniCatch open-source library.

Instead of generic error handling, AIBoundary creates an isolated quarantine zone around your GenUI components. If the LLM hallucinates or spits out malformed JSON, the boundary intercepts the crash, keeps the rest of the application (like the chat history) perfectly intact, and gracefully handles the failure in-place.

How to use it

First, install the package:

npm install @cognicatch/react

Then, simply wrap the component responsible for rendering the LLM's output:

import { AIBoundary } from '@cognicatch/react';
import { FinancialChart } from './components/FinancialChart';

export function ChatMessage({ toolInvocation }) {
  // If toolInvocation.args comes back malformed,
  // FinancialChart will crash. AIBoundary protects the app.

  return (
    <AIBoundary
      mode="manual"
      showRawData={true} 
      rawPayload={toolInvocation.args} 
      onRecover={() => triggerRetryInChatStream()}
    >
      <FinancialChart data={toolInvocation.args} />
    </AIBoundary>
  );
}

What happens under the hood?

Isolation: If FinancialChart throws TypeError: undefined is not a function because of a schema hallucination, the error is stopped dead in its tracks. The parent component (the chat window) doesn't even flinch.
Contextual Fallback: Instead of a generic "Something went wrong" message, CogniCatch displays an elegant, purpose-built Generative UI fallback.
Recovery: By providing the rawPayload, developers (or users, depending on your setup) can actually see the hallucinated output, and the onRecover action allows you to instantly trigger a retry to the LLM without reloading the page.

Open-Source vs. Auto Mode

CogniCatch is an open-core project.

The mode="manual" (open-source) is completely free and runs locally. It isolates the crash, prevents the White Screen of Death, and exposes the rawPayload so your users (or you) can see the hallucinated output, allowing them to hit "Try Again" via the onRecover callback.

But I also built a Pro Tier (mode="auto") for a fully hands-off UX:

Automatically translate the error empathetic message into the user's native browser language.
Visually parse and beautifully format the malformed JSON so developers and users can easily read what went wrong.

Join the Early Adopter Waitlist at cognicatch.dev (Early birds get 50% off the Pro tier for the first 6 months!).

Stop letting LLMs dictate your app's stability

We shouldn't let the non-deterministic nature of AI degrade the deterministic reliability of our React applications. By treating LLM outputs as highly volatile external data and wrapping them in specialized boundaries, you guarantee that an AI's mistake never becomes a user's frustration.

If you are tired of building AI wrappers that crash on unpredictable streams, give CogniCatch a try. It’s open-source, beautifully styled out of the box, and respects your telemetry.

Happy (and safe) prompting!

(Note: If you need to silently log these hallucinations to Sentry or Datadog without breaking the UI, the package also exposes an onError callback designed specifically to avoid blinding your observability tools. You can read my previous article about that here).

How to catch React errors for your users without blinding your Sentry logs

Matheus Lima — Thu, 26 Mar 2026 19:38:38 +0000

Every React developer fears the "White Screen of Death". When a single component throws an unhandled error, React unmounts the entire component tree, leaving the user staring at a blank page.

To fix this, we use Error Boundaries. But there is a hidden trap that catches even senior teams: if you catch an error locally to show a fallback UI, the error stops bubbling up. Suddenly, your app is failing in production, users are seeing a generic "Something went wrong" message, and your Sentry dashboard is completely silent. You just traded a UX nightmare for an observability nightmare.

The Traditional (and Messy) Approach

When we write custom Error Boundaries from scratch, we usually end up mixing UI logic with telemetry logic.

// The typical, messy approach
class CustomErrorBoundary extends React.Component {
  state = { hasError: false };

  componentDidCatch(error, errorInfo) {
    this.setState({ hasError: true });
    // If a dev forgets to add this line, Sentry goes blind!
    Sentry.captureException(error, { extra: errorInfo });
  }

  render() {
    if (this.state.hasError) {
      return <div className="ugly-red-box">Something went wrong.</div>;
    }
    return this.props.children;
  }
}

This scales poorly. Developers often forget to wire up the logging service when quickly wrapping a new component, and you end up rewriting fallback UIs (toasts, banners, modals) for every different part of your app.

The Solution: Separation of Concerns

Good Developer Experience (DX) is about combining the right tools for the right jobs. Sentry is incredible at backend telemetry and tracking bugs. But it shouldn't be responsible for your frontend UI.

To solve this, I built CogniCatch, an open-source React wrapper that standardizes Graceful UI Degradation. Instead of a blank screen, it replaces the broken component with standardized, empathetic UI notifications.

In my latest release (v1.1.6), I introduced a fail-safe onError callback specifically designed to solve the "swallowed error" problem.

Here is how you pair CogniCatch with Sentry to get the perfect architecture:

import * as Sentry from "@sentry/react";
import { AdaptiveErrorBoundary } from "@cognicatch/react";

export function CheckoutFlow() {
  return (
    <AdaptiveErrorBoundary 
      mode="manual"
      severity="medium"
      title="Payment Failed"
      description="We couldn't process your card right now. Please try again."
      // The magic happens here: 
      // The UI stays up, and Sentry gets the log silently.
      onError={(error, errorInfo) => {
        Sentry.captureException(error, { extra: errorInfo });
      }}
    >
      <PaymentForm />
    </AdaptiveErrorBoundary>
  );
}

The Double Benefit

By decoupling the UI degradation from the telemetry, everybody wins:

For the User (Perfect UX): Instead of a broken layout, they see a clean, localized banner (or toast) letting them know the payment failed. The rest of the application (sidebar, header, navigation) remains perfectly intact and interactive.
For the Developer (Perfect DX): The onError callback runs safely in the background inside a hardened try/catch block. Sentry immediately lights up in your Slack channel with the exact stack trace and component tree. No silent failures.

Try it out

I built CogniCatch open-source because I was tired of writing endless switch statements to map API errors and polluting my components with logger logic.

If you want to stop losing telemetry while keeping your users happy, check out the repository and give it a try.

⭐ Star CogniCatch on GitHub
npm install @cognicatch/react

Let Sentry handle the logs. Let CogniCatch handle the interface.

(Let me know in the comments how your team currently handles React fallbacks alongside your observability stack!)

Stop showing "Something went wrong" to your users. How I automated React error handling with AI

Matheus Lima — Mon, 16 Mar 2026 13:52:20 +0000

If you are a frontend or full-stack developer, you probably hate dealing with third-party API errors as much as I do.

You are building a beautiful React, tanStack or Next.js application, everything is smooth, and then you have to integrate an external API. Suddenly, your network tab is full of unpredictable errors: 503 Service Unavailable, 429 Too Many Requests, CORS preflight failed, or some bizarre custom JSON error from a legacy system.

You usually have two choices, and both of them suck:

The Exhausting Way: Write endless switch statements to map every single possible error code and translate them into human-readable messages.
The Lazy Way: Wrap everything in a try/catch and show a generic "Oops, something went wrong. Please try again later" to your user.

I got tired of wasting hours tracking down delicate component errors and writing fallback UI copy. So, I built a tool to completely automate this.

Meet CogniCatch

I built CogniCatch to be the ultimate time-saver for React developers. It's an Edge-native error analytics and UX platform that catches raw, ugly API errors and translates them into empathetic, actionable, and localized UI messages using AI.

Instead of mapping 50 different error scenarios from a public API, you just wrap your risky calls or Error Boundaries with the CogniCatch SDK.

How it saves you hours of work:

No more mapping 3rd-party errors: Whether the API fails because of a timeout, a rate limit, or a server crash, CogniCatch understands the context of the raw stack trace and generates a user-friendly explanation on the fly.
Automatic Localization: If your user speaks Portuguese, Spanish, or French, the AI automatically translates the recovery message without you having to touch an i18n JSON file.
Zero Jargon: It ensures your end-users never see words like "TCP Socket Hang up" or "Null pointer exception". It tells them exactly what happened in plain English (or their native language).

Under the Hood: Built for the Edge

As engineers, we care about latency. An error handling tool cannot slow down your app.

I built the CogniCatch infrastructure to run entirely on the Edge. Here is the stack that makes it execute in milliseconds:

Cloudflare Workers & Pages: For global, zero-cold-start execution.
Supabase (PostgreSQL) + Drizzle ORM: We bypassed traditional transaction pooling (PgBouncer) issues on the Edge, connecting directly to the database to ensure sub-500ms query times.
Upstash Redis: Distributed rate-limiting to protect the ingestion API from DDoS or abuse.
OpenAI (GPT-4o-mini): Strictly configured to return structured JSONs with title, description, and severity, while a custom PII Shielding algorithm ensures no sensitive user data ever touches the LLM.

Stop writing generic fallbacks

If you want to save time, keep your codebase clean from endless error-mapping files, and actually provide a great UX when things break, give it a try.

I'm currently opening early access to developers and provisioning the infrastructure.

🔗 Join the Early Adopter Waitlist at cognicatch.dev (Early birds get 50% off the Pro tier for the first 6 months!).

Let me know in the comments: what is the worst/most bizarre third-party API error you've ever had to handle in the frontend?