[🐛 Bug]: Minified React error #31

[haonanan]

Describe the bug
I integrated an AI model into Keep. Based on the alerts I received, I correlated them into a single incident. When I entered a prompt asking the AI to analyze the relationships between the alerts, it started running normally, but after generating output for a while, the response was interrupted by a full-page error. I’m wondering whether this is a frontend bug or if the AI’s response was simply too long.Even after restarting the entire KeepHQ, the error still persists.

To Reproduce
Steps to reproduce the behavior:

1. Go to incidents
2. Click on 'ask ai to analyze the relationships between the alerts'
3. See error

Screenshots

Additional context
Add any other context about the problem here.

[dosubot]

Hi @haonanan! I'm Dosu and I’m helping the keep team.

This error is caused by the frontend trying to render a plain object (with keys like content and providerType) as a React child, which React does not allow. In the Keep codebase, the AI chat interface (IncidentChat) stores and loads messages as objects, but there’s no explicit check to ensure that only valid React elements or strings are rendered. If the AI or backend returns a malformed or oversized response, or if the message structure is unexpected, this can trigger Minified React error #31. This is a frontend bug, not just a matter of the AI response being too long, though large or malformed responses can make it more likely to occur.

WebSocket connection failures (to localhost:6001) are likely a separate issue, handled inside the Copilot runtime layer, and not the direct cause of the React error, but they could contribute to instability if the chat relies on streaming responses.

To mitigate: try clearing your browser’s localStorage for the affected incident (since corrupted or oversized messages may persist there), reduce the size/complexity of your AI prompt, and check that the AI response is a string or valid React element before rendering. Improving error handling and adding validation/sanitization before rendering AI responses would help prevent this in the future. More context: related issue about AI input size and error handling, IncidentChat rendering logic.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[tianzhuxhc-bit]

I prepared a minimal UI-side fix for this issue.

What it changes:

• guards incident chat restore from localStorage
• accepts TextMessage.content only when it is a string, or extracts message.content.content when the stored payload is an object wrapper
• skips malformed cached messages instead of restoring invalid React children
• clears the cached entry if stored messages cannot be parsed cleanly

Why this approach:

• the reported React Providers / OpsGenie #31 error is consistent with the UI trying to render a plain object as a child
• even after restart, the page can stay broken if the bad response was already persisted in local storage
• this patch prevents corrupted persisted chat state from crashing the page again on reload

Validation:

• npm install completed successfully in keep-ui
• global npm run typecheck -- --pretty false still fails, but on pre-existing unrelated files (shared/lib/__tests__/provider-utils.test.ts and widgets/workflow-builder/__tests__/workflow-builder.test.tsx)
• targeted eslint on app/(keep)/incidents/[id]/chat/incident-chat.tsx returns 0 errors (2 existing hook warnings)

Because my account is still fork-restricted, I can't open a normal PR right now. I prepared both a diff and a git format-patch for maintainers to review/cherry-pick if this direction looks acceptable.

[tianzhuxhc-bit]

Patch package (diff, format-patch, notes): https://gist.github.com/tianzhuxhc-bit/bb7638c8750cc1b94150f8a88e9988db