What happened?
When a workflow produces a large result/status update — for example a workflow with many operators, or one ending in a visualization operator (such as Bar Chart) whose rendered payload is sizable — the frame that the computing unit pushes to the browser over the WebSocket can exceed the default maximum WebSocket message size of 64 KB (web-server.max-workflow-websocket-request-payload-size-kb = 64, applied to the Jetty container by WebsocketPayloadSizeTuner).
Jetty then rejects the entire frame:
org.eclipse.jetty.websocket.api.MessageTooLargeException: Resulting message size [NNNNN] is too large for configured max of [65536]
Because the whole frame is dropped, the frontend never receives the final result. The execution itself completes successfully on the backend (workflow status = COMPLETED), but the affected operator's result/visualization never renders in the UI — so it looks like the final operator (e.g. the bar chart) "did not run". The overshoot is often small (observed frames of ~66–72 KB, only a couple KB over the 64 KB cap), so even fairly modest workflows can trip it.
How to reproduce?
- Build a workflow ending in a visualization operator (e.g. Bar Chart) with enough categories/series that its serialized result payload, combined with the other operators' status, exceeds 64 KB — or a workflow with a large number of operators.
- Run it to completion.
- Observe that the backend reports the execution as COMPLETED, but the final visualization does not appear in the UI.
- Inspect the computing unit logs — a
MessageTooLargeException: ... too large for configured max of [65536] is logged at the moment of completion.
Version/Branch
main
What happened?
When a workflow produces a large result/status update — for example a workflow with many operators, or one ending in a visualization operator (such as Bar Chart) whose rendered payload is sizable — the frame that the computing unit pushes to the browser over the WebSocket can exceed the default maximum WebSocket message size of 64 KB (
web-server.max-workflow-websocket-request-payload-size-kb = 64, applied to the Jetty container byWebsocketPayloadSizeTuner).Jetty then rejects the entire frame:
Because the whole frame is dropped, the frontend never receives the final result. The execution itself completes successfully on the backend (
workflow status = COMPLETED), but the affected operator's result/visualization never renders in the UI — so it looks like the final operator (e.g. the bar chart) "did not run". The overshoot is often small (observed frames of ~66–72 KB, only a couple KB over the 64 KB cap), so even fairly modest workflows can trip it.How to reproduce?
MessageTooLargeException: ... too large for configured max of [65536]is logged at the moment of completion.Version/Branch
main