Opening a thread can trigger React error #185 and leave a blank screen

[ratulsarna]

Summary

Opening an existing thread can trigger React error #185 and leave the entire bb web app as a blank dark screen.

I observed this failure directly in Chrome and captured the console error. The exact thread-data condition is not yet isolated, so there is no shareable reproduction recipe yet.

Environment

• bb: 0.36.0
• Client: bb web app in Chrome on macOS
• Route shape: /projects/<project-id>/threads/<thread-id>
• The served asset hashes match the packaged 0.36.0 build

Expected

The thread page renders normally. A problem in the composer should not take down the whole route.

Actual

The route renders as a completely blank dark page with no recovery UI.

Console error

Error: Minified React error #185; visit https://react.dev/errors/185
    at _i (dist-CiVt1nMI.js:8:27500)
    at mi (dist-CiVt1nMI.js:8:27025)
    at zs (dist-CiVt1nMI.js:8:58555)
    at Rs (dist-CiVt1nMI.js:8:58177)
    at Ue (workspace-checkout-display-Bf-7ns1Z.js:507:123482)
    at Kc (dist-CiVt1nMI.js:8:91672)
    at ll (dist-CiVt1nMI.js:8:96131)
    at Cl (dist-CiVt1nMI.js:8:104917)
    at ll (dist-CiVt1nMI.js:8:96118)
    at Cl (dist-CiVt1nMI.js:8:104917)

React error #185 decodes to “Maximum update depth exceeded.”

Source investigation

The minified Ue frame at the reported byte offset maps to the stack-height measurement in:

apps/app/src/components/promptbox/FollowUpPromptBox.tsx

useLayoutEffect(() => {
  const element = stackRef.current;
  if (!element) return;
  const measured = element.offsetHeight;
  setStackHeight((prev) => (prev === measured ? prev : measured));
}, [stack]);

The same component also updates stackHeight from a ResizeObserver, and then derives the prompt textarea minimum height from stackHeight.

Likely cause: a layout/state feedback loop where the measured stack height and elastic textarea height keep affecting each other. This is an investigation lead, not yet a proven root cause.

The code is unchanged on current main at the time of filing.

This appears separate from #767, which fixed a ResizeObserver/render loop in GeneratedConversationMessage.

Workaround

The affected thread can still be read and continued through bb thread CLI commands against the same server. Avoiding the thread route is the only confirmed workaround so far.