Use separate sequence numbers for each workflow operation type #26
Conversation
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
### Motivation Temporal's workflow state machine previously used a single shared sequence number counter for all operation types (timers, activities, conditions, child workflows, and external signals). This could potentially lead to confusion when tracking different types of operations, as each operation type needs its own independent sequence numbering to properly identify activation jobs. ### Modifications - Split the single `nextSequenceNumber` into five operation-specific counters: - `nextTimerSequenceNumber` for sleep operations - `nextActivitySequenceNumber` for activity executions (local and remote) - `nextConditionSequenceNumber` for wait conditions - `nextChildWorkflowSequenceNumber` for child workflow executions - `nextExternalSignalSequenceNumber` for signaling external workflows - Updated all sequence number generation methods to use the appropriate counter - Updated `WorkflowStateMachineStorage` to call the correct sequence number method for each operation type - Enhanced documentation to clarify that each operation type maintains independent sequence counters ### Result Each workflow operation type now maintains its own independent sequence counter, making the sequence numbering system more robust and easier to reason about. This ensures that activation jobs can be correctly matched to their originating commands without any ambiguity across different operation types.
philippzagar
approved these changes
Oct 10, 2025
There was a problem hiding this comment.
Looks great, thanks for the improvement and nice docs @FranzBusch! 🚀
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.
Motivation
Temporal's workflow state machine previously used a single shared sequence number counter for all operation types (timers, activities, conditions, child workflows, and external signals). This could potentially lead to confusion when tracking different types of operations, as each operation type needs its own independent sequence numbering to properly identify activation jobs.
Modifications
Split the single
nextSequenceNumberinto five operation-specific counters:nextTimerSequenceNumberfor sleep operationsnextActivitySequenceNumberfor activity executions (local and remote)nextConditionSequenceNumberfor wait conditionsnextChildWorkflowSequenceNumberfor child workflow executionsnextExternalSignalSequenceNumberfor signaling external workflowsUpdated all sequence number generation methods to use the appropriate counter
Updated
WorkflowStateMachineStorageto call the correct sequence number method for each operation typeEnhanced documentation to clarify that each operation type maintains independent sequence counters
Result
Each workflow operation type now maintains its own independent sequence counter, making the sequence numbering system more robust and easier to reason about. This ensures that activation jobs can be correctly matched to their originating commands without any ambiguity across different operation types.