fix(ext-workflow): honor DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES on workflow channels#1085
Open
tezizzm wants to merge 1 commit into
Open
fix(ext-workflow): honor DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES on workflow channels#1085tezizzm wants to merge 1 commit into
tezizzm wants to merge 1 commit into
Conversation
…workflow channels Workflow activity payloads over gRPC's 4 MiB default raised RESOURCE_EXHAUSTED because the durabletask channel ignored the message size limit. dapr#1024 plumbed DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES through the Dapr API channel only; the workflow worker and clients still fell back to the gRPC default. Add a get_grpc_channel_options helper that resolves the limit from an explicit max_grpc_message_length kwarg, then the env var, then None, and thread it through WorkflowRuntime, DaprWorkflowClient, and the async DaprWorkflowClient. Unlike dapr#1024, set both send and receive limits symmetrically since workflow payloads cross the channel in both directions. Reuses the existing setting; no new env var. Signed-off-by: Martez Killens <5050479+tezizzm@users.noreply.github.com>
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
1 participant
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.
Description
Long-running workflows whose activity results exceed gRPC's 4 MiB default fail with
RESOURCE_EXHAUSTED: Sent message larger than max (X vs. 4194304). #1024 addedDAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTESand threaded it through the Dapr APIchannel only — it did not cover the workflow (durabletask) channel, so even with
the env var exported, workflows still hit the 4 MiB ceiling once the orchestration
history (input + accumulated activity results) crossed the limit.
This PR mirrors the #1024 pattern in
dapr-ext-workflow:get_grpc_channel_options()helper indapr/ext/workflow/util.py. Resolutionorder: explicit
max_grpc_message_lengthkwarg →settings.DAPR_GRPC_MAX_INBOUND_MESSAGE_SIZE_BYTES→
None(gRPC default).max_grpc_message_length: Optional[int] = Nonekwarg throughthe three workflow gRPC constructors and passes the resolved
channel_options:WorkflowRuntime.__init__→TaskHubGrpcWorkerDaprWorkflowClient.__init__(sync) →TaskHubGrpcClientaio.DaprWorkflowClient.__init__(async) →AsyncTaskHubGrpcClientprecedence.
Unlike #1024, the limit is applied symmetrically to both send and receive, because
workflow activity payloads cross the channel in both directions (worker → daprd carries
activity output too); #1024 only set the receive limit in its env-var branch.
No new environment variable is introduced (reuses #1024's), and no vendored
_durabletask/internals ordapr/proto/files are touched.Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #1084
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list: