Application error: a client-side exception has occurred while loading localhost
First Published: 2025-06-04
Last Updated: 2025-06-20
Documenting a server-side bug which occured when migrating from Next.js 15.1.x
TLDR
The Windows server sent a UTF-8 encoded file with CP-1252 encoding instead.
Background
This occured when I was developing Subtext.
Subtext uses a custom Python FastAPI setup for hosting the Frontend which is a static Next.js site.
Until this bug I hadn't had any issues with this setup.
The Bug
When I was updating Subtext, I wanted to bump the Next.js version, if only to stop the annoying dependabot CVE-2025-29927 warnings.
So I did, and nothing went wrong, and everything worked perfectly in dev.
Then I sent it to the build server and the bug happened: every build would build without issues.
But when running the builds, I would get this error: Application error: a client-side exception has occurred while loading localhost (see the browser console for more information).
and there would be three errors in the console
No group found for id "«Rufb»"
No group found for id "«Rfb»"
Uncaught Error: No group found for id "«Rufb»"
Debugging
When I searched Google, very fortunately the first result was relevant.
It revealed that this issue had occured before in the react-resizable-panels package before.
Since I was using react-resizable-panels through the ShadCN Resizable element, through some testing, I was able to isolate this bug to some interaction with the Resizable component.
I then made a barebones create-next-app application, with only a ShadCN Resizable component and was able to recreate the issue when the application was exported and hosted via my backend.
Since this only occured when the application was exported and hosted and not in dev, I spun up a NGINX vm for debugging with the exact same build that was causing issues.
I had expected to encounter the exact same bug again, but it worked flawlessly.
This meant that it was my FastAPI backend which caused this error.
I first compared the FastAPI and NGINX requests against the same file in the network tab, and there were no obvious differences, no file fetches failed and each file fetched was the same size.
I then spun up a script which queried the same file from both servers and diffed them.
This script then flagged index.html which showed that NGINX returned
data-panel-id="«R6fb»"while FastAPI returned
data-panel-group-id="«Rfb»"
Conclusion
Eventually, I found the root cause of the bug:
return HTMLResponse(open(static_file_path, "r").read())
And the fix:
return HTMLResponse(open(static_file_path, "r", encoding="utf-8").read())
Explanation: In open(), if encoding is not set to anything, by default Python will use the default system encoding:locale.getencoding()
On Windows, this returns CP-1252. When Python opened and read the UTF-8 file using CP-1252, it stripped the  character from data-panel-id which broke the application as React could no longer find the element.
The upgrade to Next.js 15.2.x or 15.3.x is what triggered the bug as previously in 15.1.x, the exported html had a data-panel-group-id of :R2ftb:.
Note: If anyone finds it useful, they can find the testing repo here: https://github.com/jchu634/next-export-test