Repository navigation
fix(workflow): accept work items larger than gRPC's 4MB default - #1337
Merged
CasperGN merged 1 commit intoOct 22, 2026
Merged
Conversation
The workflow worker's gRPC channel kept gRPC's default 4MB receive limit unless the app set max_grpc_message_length or DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES. The sidecar sends work items up to its own max body size, which apps raise for large payloads, so a work item over 4MB (for example a fan-out of five 1MB activity results) failed the stream with RESOURCE_EXHAUSTED. The worker reconnected, the sidecar redelivered the same work item, and it failed again, so every workflow on the worker stalled. Signed-off-by: joshvanl <me@joshvanl.dev>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1337 +/- ##
==========================================
+ Coverage 87.27% 87.33% +0.06%
==========================================
Files 163 163
Lines 13069 13069
==========================================
+ Hits 11406 11414 +8
+ Misses 1663 1655 -8 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused change preserves explicit limits and includes targeted regression coverage, with no unresolved findings.
No open issues 🎉
What changed in this PR
This PR removes the workflow worker’s default 4 MiB receive limit so large work items do not cause repeated stream failures and stall workflows.
Changes:
- Allows unlimited receive size by default while preserving explicitly configured limits.
- Adds regression tests for oversized work-item processing and explicit-limit precedence.
- Updates runtime documentation to describe the new default behavior.
| File | Description |
|---|---|
tests/ext/workflow/durabletask/test_worker_large_work_item.py |
Tests large work-item delivery and explicit receive-limit preservation. |
dapr/ext/workflow/workflow_runtime.py |
Documents the default send and receive behavior. |
dapr/ext/workflow/_durabletask/worker.py |
Sets an unlimited default receive size before applying caller options. |
Review effort: Balanced
CasperGN
approved these changes
Oct 22, 2026
dapr-bot
added a commit
that referenced
this pull request
Oct 22, 2026
… (#1339) The workflow worker's gRPC channel kept gRPC's default 4MB receive limit unless the app set max_grpc_message_length or DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES. The sidecar sends work items up to its own max body size, which apps raise for large payloads, so a work item over 4MB (for example a fan-out of five 1MB activity results) failed the stream with RESOURCE_EXHAUSTED. The worker reconnected, the sidecar redelivered the same work item, and it failed again, so every workflow on the worker stalled. (cherry picked from commit ba2b297) Signed-off-by: joshvanl <me@joshvanl.dev> Signed-off-by: dapr-bot <dapr-bot@users.noreply.github.com> Co-authored-by: Josh van Leeuwen <me@joshvanl.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The workflow worker's gRPC channel kept gRPC's default 4MB receive limit unless the app set max_grpc_message_length or DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES. The sidecar sends work items up to its own max body size, which apps raise for large payloads, so a work item over 4MB (for example a fan-out of five 1MB activity results) failed the stream with RESOURCE_EXHAUSTED. The worker reconnected, the sidecar redelivered the same work item, and it failed again, so every workflow on the worker stalled.