Repository navigation
馃挜 Enforce payload and memo size limits - #3149
Draft
jmaeagle99 wants to merge 1 commit into
Draft
jmaeagle99 wants to merge 1 commit into
jmaeagle99 wants to merge 1 commit into
Conversation
This branch has not been deployed
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.
What was changed
Workers now enforce the namespace's payload and memo size limits before sending, and every client warns about oversized payloads.
Validation at the gRPC layer. A new interceptor in
temporal-serviceclientchecks every WorkflowService request on the final message, after user interceptors have run. Fields over a warning threshold are logged with[TMPRL1103]and still sent. When a call carries error limits and a field exceeds them, the call fails locally withINVALID_ARGUMENTand is never sent or retried.Worker enforcement. Workers read the namespace's blob and memo error limits from the
DescribeNamespacecall they already make at startup. They attach the limits only to their own completion and heartbeat calls, so other client calls only warn. Each worker turns a rejected call into a retryable failure instead of sending it:PAYLOADS_TOO_LARGE.ApplicationFailureof typePayloadsTooLarge.Each case records a
PayloadsTooLargefailure reason on the existing task failure metrics.Configuration.
WorkflowServiceStubsOptions.Builder.setPayloadLimitssets the warning thresholds: 512 KiB per payload and 2 KiB per memo by default, with 0 disabling a warning. It is experimental.WorkerOptions.Builder.setDisablePayloadErrorLimitturns off worker enforcement.Why?
The server already rejects oversized payloads, but harshly: it terminates the workflow, or fails the activity non-retryably. Failing the task retryably in the worker lets a corrected workflow or activity be redeployed and recover. This also brings Java in line with the core-based SDKs and Go, which already enforce these limits.
Checklist