Send raw history blobs from history service to frontend #7179
Conversation
This file contains 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
…istory API from history service
prathyushpv
force-pushed
the
ppv/raw_history
branch
from
66cd80b to
138b056
Compare
dnr
reviewed
Jan 30, 2025
| switch data.EncodingType { | ||
| case enumspb.ENCODING_TYPE_PROTO3: | ||
| err = proto.UnmarshalOptions{ | ||
| DiscardUnknown: true, |
There was a problem hiding this comment.
maybe add a comment here that this option is key to the performance gains
| @@ -65,3 +66,28 @@ message TaskRange { | |||
| TaskKey inclusive_min_task_key = 1; | |||
| TaskKey exclusive_max_task_key = 2; | |||
| } | |||
|
|
|||
| message StrippedHistoryEvent { | |||
There was a problem hiding this comment.
Add a comment that this is a subset of HistoryEvent
| message GetWorkflowExecutionHistoryResponse { | ||
| repeated bytes history = 1; | ||
| // Raw history is an alternate representation of history that may be returned if configured on | ||
| // the frontend. This is not supported by all SDKs. Either this or `history` will be set. |
There was a problem hiding this comment.
remove the comment about supported by SDKs? that's not relevant here, right?
There was a problem hiding this comment.
yeah right. Removed it.
| @@ -981,6 +981,10 @@ message GetWorkflowExecutionHistoryResponse { | |||
| temporal.api.workflowservice.v1.GetWorkflowExecutionHistoryResponse response = 1; | |||
| } | |||
|
|
|||
| message GetWorkflowExecutionHistoryResponseWithRaw { | |||
There was a problem hiding this comment.
add a comment that this is wire-compatible with GetWorkflowExecutionHistoryResponse?
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 changed?
Change to send raw history blobs from history service to frontend service. History service returns a new proto message that has a repeated bytes history field.
This response is wire compatible with the original response which has temporal.api.history.v1.History type for this field. This allows history service to not deserialize events from this data blob. This considerably reduces CPU usage.
History service still needs event_id and version decoded from history events. For this we use a new proto message StrippedHistoryEvent which has these two fields only. It takes considerably less CPU to decode events to this struct.
Why?
We have seen incidents of high history CPU usage when large number of GetWorkflowExecutionHistory calls are made to workflows which has large history. With this change we can reduce the CPU burden on history service during this API call.
How did you test it?
Existing unit tests and manual test to run workflows.
Potential risks
Documentation
Is hotfix candidate?
No