Repository navigation
Desktop orchestrator logs uncaught exception on malformed Convex sync frame - app recovers, but handler should catch parse failures #16
Description
Summary
The Freebuff Windows desktop app logs an uncaught exception when a malformed
JSON frame arrives over the Convex sync websocket. The app recovers and keeps
working, but the exception escaping the message handler is unhandled.
Error
From %APPDATA%\Freebuff\logs\orchestrator-stderr.log:
[CONVEX FATAL ERROR] Received Invalid JSON on websocket: unexpected end of hex escape at line 1 column 543019
freebuff-desktop uncaught_exception: Error: [CONVEX FATAL ERROR] Received Invalid JSON on websocket: unexpected end of hex escape at line 1 column 543019
at onMessage (resources/orchestrator/orchestrator.js:192891:40)
at <anonymous> (resources/orchestrator/orchestrator.js:192225:25)
unexpected end of hex escape means the payload ends partway through a
\uXXXX escape sequence, so the frame is already malformed when the client
begins to parse it.
Impact
Non-fatal. An earlier revision of this report stated the workspace never
loads. That was wrong. Measured on a cold start with a clean process slate:
| Event | Local time (2026-10-03) |
|---|---|
| App launch | 1:54:16 PM |
| Orchestrator listening | 1:54:17 PM |
| Workspace fully rendered | 1:54:47 PM (t+31s) |
CONVEX FATAL ERROR logged |
after render |
The workspace renders normally at roughly 31 seconds, and the exception fires
afterwards. The UI shows projects, threads, agent queues, and account state, and
the orchestrator process stays alive and keeps serving. No crash appears in the
Windows Application event log.
The concern is therefore robustness rather than availability: a JSON.parse
failure in a websocket message handler should be treated as a reconnectable
condition, not allowed to escape as an uncaught exception.
Reproduction
- Install Freebuff desktop 0.0.156 or later on Windows 11.
- Launch and sign in so the Convex sync connects.
- The workspace renders at roughly t+31s.
- The malformed frame arrives shortly after and the error above is logged.
Versions tested
| Version | Result |
|---|---|
| 0.0.156 | fails, column 543019 |
| 0.0.158 (latest) | fails, column 543018 |
Note the column varies by one character between runs, so it is not a fixed
truncation point. An earlier revision of this report called it an identical
offset on both versions; that was overstated.
What has been ruled out
- Backend outage.
GET /onharmless-tapir-303.convex.cloudreturns 200
withThis Convex deployment is running. - Stale client. 0.0.158 is the newest published desktop release; there is no
0.0.159. - Truncation by the Bun WebSocket implementation. Tested with the app's own
Bun 1.4.2: a 1,143,047 byte JSON message sent from aBun.servewebsocket
server to a Bun client arrived fully intact and parsed cleanly. A ~543 KB
frame is not being cut short locally by the runtime. - Orphaned or conflicting processes. The process tree is clean and correctly
parented. - App crash. No corresponding Windows Application event log entry.
- Local cache corruption. Nothing malformed found in the app's IndexedDB,
WebStorage, or partition storage.
Note on a false lead
During diagnosis the app appeared to quit on its own. That was electron-updater
installing 0.0.158 on exit, not a separate defect. The error reproduces on both
versions and is unrelated to the update.
Question
Since the frame appears to be malformed as received, is this a Convex sync
server issue, or a defect in the bundled Convex client's message assembly in
orchestrator.js? Happy to provide the raw frame or additional logging if that
would help.
Activity
tmurphy24-lab commentedon Oct 3, 2026
Correction: this error does NOT prevent the workspace from loading
I originally filed this as a blocker ("workspace never loads"). That claim was
wrong, and I want to correct it rather than leave a misleading report open.
I captured the app window after the error had already fired and the workspace
had rendered normally:
CONVEX FATAL ERRORloggedAt screenshot time, roughly 9 minutes after the exception, the UI was fully
populated: the
manufacturing-erpproject and its threads were listed, thesidebar showed account state, and agent queues were rendering and progressing.
The orchestrator process stayed alive and kept serving on its port throughout.
So the sequence is: the malformed frame throws, the client reconnects, and the
app recovers. My earlier read treated a logged exception as a fatal state
without checking the UI.
Revised, accurate report
The real defect is narrower and is a robustness issue rather than an outage:
column 543019.
uncaught_exceptionis never caught. It is logged and theprocess survives, but an uncaught exception escaping a message handler is
fragile: any code path that depends on that handler's post-
JSON.parsebehaviour could misbehave, and the connection only recovers because the client
happens to reconnect.
The investigation below still holds for the error itself (it reproduces at the
identical byte offset on 0.0.156 and 0.0.158, the backend is healthy, and Bun
1.4.2 does not truncate large WebSocket messages). Only the impact assessment in
the original report was wrong.
Suggested ask: catch parse failures in the sync
onMessagehandler and treatthem as a reconnectable condition rather than letting them escape as uncaught.
Apologies for the noise.
[-]Desktop workspace never loads: deterministic malformed Convex sync frame (column 543019) on Windows[/-][+]Desktop orchestrator logs uncaught exception on malformed Convex sync frame (column 543019) - app recovers, but handler should catch parse failures[/+][-]Desktop orchestrator logs uncaught exception on malformed Convex sync frame (column 543019) - app recovers, but handler should catch parse failures[/-][+]Desktop orchestrator logs uncaught exception on malformed Convex sync frame - app recovers, but handler should catch parse failures[/+]