Skip to content

fix(v1.2): raise default WebSocket payload limit to avoid dropping large result frames - #7811

Draft
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/6858-raise-default-websocket-payload-limit-to-v1.2
Draft

fix(v1.2): raise default WebSocket payload limit to avoid dropping large result frames#7811
github-actions[bot] wants to merge 1 commit into
release/v1.2from
backport/6858-raise-default-websocket-payload-limit-to-v1.2

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

What changes were proposed in this PR?

Automated backport of #6858 to release/v1.2.

Source: 25b2083 · automation run

Any related issues, documentation, discussions?

Backport of #6858. Originally linked #6857.

How was this PR tested?

Release-branch CI runs on this branch once the conflicts are resolved and this PR is marked ready for review.

Was this PR authored or co-authored using generative AI tooling?

No.

…sult 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

---------

(backported from commit 25b2083)

Signed-off-by: ali <ali.risheh876@gmail.com>
Co-authored-by: Yicong Huang <17627829+Yicong-Huang@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor Author

The cherry-pick conflicted and was committed with conflict markers. Resolve the conflicts on this branch, then mark this PR ready for review.

Conflicting files:

  • common/config/src/test/scala/org/apache/texera/common/config/ApplicationConfigSpec.scala

@xuang7

xuang7 commented Aug 24, 2026

Copy link
Copy Markdown
Contributor

Please take a look at this backport PR, as the automatic backport failed, and mark it as ready for review once it’s ready. Thanks, @aicam

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants