asyncapi / asyncapi/website

[BUG] Missing React error boundaries - application crashes on any component error

Open
#5,047 3 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
TypeScript
Stars
716
Forks
1.2k
Avg merge
1d 12h
Merged PRs (30d)
35

Description

### Describe the bug.

The AsyncAPI website application currently has **no React error boundaries** implemented. When any component throws an unhandled error during rendering, the entire application crashes and users see a blank white screen instead of a graceful error fallback UI.

## Current Behavior

- ❌ No error boundaries in `pages/_app.tsx` (root component)
- ❌ No error boundaries in layout components (`Layout.tsx`, `DocsLayout.tsx`, `BlogLayout.tsx`)
- ❌ No error boundaries in page components
- ❌ Any unhandled React error crashes the entire application
- ❌ Users see blank white screen when errors occur
- ❌ No error logging or reporting to monitoring services
- ❌ No user-friendly error messages

### Expected behavior

- ✅ Error boundaries at strategic points (app root, layouts, pages)
- ✅ Graceful error fallback UI with user-friendly messages
- ✅ Partial application functionality when possible (e.g., navigation still works)
- ✅ Error logging to monitoring service (Sentry, Winston, etc.)
- ✅ Error reporting with context (component, user, route, etc.)
- ✅ Option to retry or navigate away from error state

### Screenshots

### Development Mode - Error Overlay
Image

**What this shows:**
- When a component error occurs, Next.js shows a development error overlay
- The error is uncaught (no error boundary)
- Error details: `pages\index.tsx (16:11) @ HomePage`
- The entire application is blocked by this error overlay

**Production Impact:**
In production builds, users would see a **blank white screen** instead of this error overlay, resulting in a poor user experience with no indication of what went wrong.

Image

### Expected Behavior (After Fix)
After implementing error boundaries, users should see:
- A user-friendly error message
- Option to retry or navigate away
- Partial application functionality (e.g., navigation still works)
- Error logged to monitoring service

### How to Reproduce

1. Open the AsyncAPI website in a browser
2. Open browser DevTools Console
3. Inject an error into any component (e.g., add `throw new Error('Test error')` in a component's render)
4. Observe the result:
- The entire application crashes
- User sees a blank white screen
- Console shows unhandled error
- No error boundary catches the error

**Alternative method:**
- Use React DevTools to simulate component errors
- Or modify a component to throw an error during development

### 🖥️ Device Information [optional]

- Operating System (OS): Window 10
- Browser: Google Chrome
- Browser Version: 135.0

### 👀 Have you checked for similar open issues?

- [x] I checked and didn't find similar issue

### 🏢 Have you read the Contributing Guidelines?

- [x] I have read the [Contributing Guidelines](https://github.com/asyncapi/.github/blob/master/CONTRIBUTING.md)

### Are you willing to work on this issue ?

Yes I am willing to submit a PR!

Contributor guide

Open the contributing guide

Research direction

Start by reviewing pages/_app.tsx and the mentioned Layout.tsx, DocsLayout.tsx, and BlogLayout.tsx files, then reproduce the failure by throwing an error during component rendering. Define boundaries and fallback behavior at the app, layout, and page levels, including retry or navigation, partial functionality, and error logging with context; done means the documented crash shows a user-friendly fallback instead of a blank screen.

Written by the indexing model from the issue text.

Assessment

Tech stack
nextjs, react, typescript
Domain
frontend, observability
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.