Skip to content

State the existing aggregate transport limit in 4.15 release notes #253

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rmcdaniel merged 1 commit into from
Nov 13, 2026
Merged

State the existing aggregate transport limit in 4.15 release notes #253

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,13 @@
child workflows or continue as new. Other 413 and 5xx responses are
unchanged. The README documents the completion size limit.

**Known transport limitation:** this typed failure requires the Server's
HTTP 413 to reach the worker. An aggregate over-limit request can currently
lose that response and return a transport error instead. Automatic
structural failure for that path is not yet qualified. The Server response
correction and published-artifact controls remain open in
[the fan-out issue](https://github.com/durable-workflow/.github/issues/228).

- An update whose wait ends before its handler finishes now returns
`Error::UpdateStillPending` instead of `Ok(Null)` (durable-workflow/.github#212).
`update_workflow` used to return the Server's `result: null` for a 202
Expand Down
10 changes: 9 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -730,7 +730,15 @@ each command's arguments must still fit the per-payload limit. A larger
completion, usually a very large fan-out, is refused with HTTP 413,
`reason: "payload_too_large"` and `limit_kind: "workflow_task_completion_bytes"`.

The SDK treats that refusal as a structural limit, not a transient error. It
Automatic structural failure requires the HTTP 413 to reach the worker. A
current native Server transport defect can close an over-limit request before
that response is read. In that case the SDK reports a transport error, and the
run is not yet guaranteed to fail structurally. Follow the
[aggregate transport correction](https://github.com/durable-workflow/server/issues/1136)
and [published fan-out acceptance](https://github.com/durable-workflow/.github/issues/228)
before relying on automatic recovery from an over-limit completion.

When the typed refusal reaches the SDK, it is a structural limit. It
never resends the oversized completion. `Client::complete_workflow_task` returns
`Error::WorkflowTaskCompletionTooLarge`, which carries the Server's `limit`, the
encoded request `size` the SDK sent, and the Server's message. A `Worker`
Expand Down
Loading