The GitHub Actions job "Comment commands" on texera.git/main has succeeded. Run started by GitHub user tanishqgandhi1908 (triggered by tanishqgandhi1908).
Head commit for run: 25b208388100c49280eb6511f50c330db7b711aa / ali risheh <[email protected]> fix: raise default WebSocket payload limit to avoid dropping large result frames (#6858) ### What changes were proposed in this PR? Raises the default maximum workflow WebSocket message size from **64 KB to 1024 KB (1 MB)**, in every place the default is encoded: - `common/config/src/main/resources/application.conf` — the base config default (`web-server.max-workflow-websocket-request-payload-size-kb`) - `bin/k8s/values.yaml` — the Helm chart env default (`MAX_WORKFLOW_WEBSOCKET_REQUEST_PAYLOAD_SIZE_KB`), which overrides the base default in Kubernetes deployments - `bin/k8s/values-development.yaml` — the same env var in the development chart, which otherwise kept reproducing #6857 - `common/config/src/test/scala/.../ApplicationConfigSpec.scala` — the guard test asserting the default `WebsocketPayloadSizeTuner` applies this value to the Jetty WebSocket container's max text/binary message buffer. At the previous 64 KB default, the result/status frame pushed to the browser for a workflow with many operators or a sizable visualization payload (e.g. a Bar Chart) could exceed 65536 bytes; Jetty then drops the entire frame with `MessageTooLargeException`, so the final result/visualization never reaches the frontend even though the execution completes successfully on the backend. The overshoot is often only a couple KB, so even modest workflows can trip it. 1 MB gives ample headroom for large visualization payloads while remaining well within reasonable WebSocket frame sizes. This changes only a default value; the limit remains overridable via the `MAX_WORKFLOW_WEBSOCKET_REQUEST_PAYLOAD_SIZE_KB` environment variable. ### Any related issues, documentation, discussions? Closes #6857 ### How was this PR tested? Updated the existing guard test in `ApplicationConfigSpec` (`maxWorkflowWebsocketRequestPayloadSizeKb shouldBe 1024`), which covers the base config default. Manually verified the runtime behavior. Ran a workflow ending in a Bar Chart whose serialized result frame exceeded 64 KB: - **Before:** the visualization did not render, and the computing unit logged `MessageTooLargeException: ... too large for configured max of [65536]` at completion. - **After:** the frame is delivered and the chart renders. Also verified with `helm template` that the rendered chart env value updates to `1024` and that both charts still render cleanly. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.8 --------- Signed-off-by: ali <[email protected]> Co-authored-by: Yicong Huang <[email protected]> Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/32422266704 With regards, GitHub Actions via GitBox
