Add SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_SIGNALS enum value#822
Open
nitishagar wants to merge 1 commit into
Open
Add SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_SIGNALS enum value#822nitishagar wants to merge 1 commit into
nitishagar wants to merge 1 commit into
Conversation
Add a new SuggestContinueAsNewReason value so the server can advise a workflow to continue-as-new when its signal count approaches maximumSignalsPerExecution, before the hard ErrSignalsLimitExceeded rejection. This is the signals analog of the existing TOO_MANY_UPDATES reason.
|
Nitish Agarwal seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
5 tasks
nitishagar
pushed a commit
to nitishagar/temporal
that referenced
this pull request
Jul 9, 2026
Add a fourth SuggestContinueAsNewReason, TOO_MANY_SIGNALS, so the server advises a workflow to continue-as-new when its signal count reaches a configurable fraction of maximumSignalsPerExecution, before the hard ErrSignalsLimitExceeded rejection bites. This is the signals analog of the existing TOO_MANY_UPDATES suggest-CAN feature. The suggestion is computed inline in getHistorySizeInfo alongside the existing history-size and history-event-count reasons (signals have no registry, so inline computation reuses the scope already established there). It fires when SignalCount >= ceil(maximumSignalsPerExecution * threshold), mirroring the updates path's rounding. The threshold is a new namespace-scoped dynamic-config key history.maximumSignalsPerExecution.suggestContinueAsNewThreshold that defaults to 0 (disabled), so the feature is opt-in and a strict no-op on upgrade. The hard-limit rejection path is unchanged. Requires go.temporal.io/api to export SUGGEST_CONTINUE_AS_NEW_REASON_TOO_MANY_SIGNALS (added in temporalio/api#822); go.mod temporarily points at a fork until that version is released. Closes temporalio#10941.
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
2 participants
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 changed?
Adds a new value to the
SuggestContinueAsNewReasonenum:placed after the existing
reserved 4block, following the file's enum-ordering style.Why?
Resolves the API/proto portion of temporalio/temporal#10941.
Today the server has a hard limit on signals (
maximumSignalsPerExecution, default 10000) that rejects new signals outright viaErrSignalsLimitExceeded, but no softsuggest-continue-as-newpathway that warns the worker before the hard limit bites — unlike history size, history event count, and updates, which all already have a correspondingSuggestContinueAsNewReason.This PR adds only the enum value. The server-side companion PR wires it into the suggest computation (a new namespace-scoped threshold config key), the metric tag, and the persisted/SDK-visible reasons field. This mirrors how
TOO_MANY_UPDATEScame to exist upstream before the server consumed it.Breaking changes
None. Appending a new enum value to a proto3
enumis wire-compatible (the persistedWorkflowTaskSuggestContinueAsNewReasonsis a repeatedint32; older readers round-trip the unknown int, regenerated SDKs see the named constant). No existing value changes.Server PR
temporalio/temporal#10941 (companion server PR to follow this merge): adds the
history.maximumSignalsPerExecution.suggestContinueAsNewThresholddynamic-config key, the inline suggest computation inworkflow_task_state_machine.go, theSuggestContinueAsNewReasonTooManySignalsmetric tag, and tests. The feature defaults to disabled (threshold0), so it is a strict no-op for any deployment that does not opt in.