Send raw history blobs from history service to frontend #7179
Conversation
…istory API from history service
prathyushpv
force-pushed
the
ppv/raw_history
branch
from
66cd80b to
138b056
Compare
| 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?
| @@ -177,6 +179,33 @@ func (t *serializerImpl) DeserializeEvents(data *commonpb.DataBlob) ([]*historyp | |||
| return events.Events, nil | |||
| } | |||
|
|
|||
| func (t *serializerImpl) DeserializeStrippedEvents(data *commonpb.DataBlob) ([]*historyspb.StrippedHistoryEvent, error) { | |||
There was a problem hiding this comment.
can we add a test for this? To make sure the two proto defs are wire compatible and also unknown fields are dropped during decoding (i.e. no unknown field is empty).
There was a problem hiding this comment.
Added a test for this.
Also added a test to verify that HistoryService's response is wire compatible with GetWorkflowExecutionHistoryResponse.
| @@ -305,3 +305,91 @@ func validateTransientWorkflowTaskEvents( | |||
|
|
|||
| return nil | |||
| } | |||
|
|
|||
| func FixFollowEvents( | |||
There was a problem hiding this comment.
nit: move this function to service/frontend if it's no longer used by history service?
Co-authored-by: Yichao Yang <[email protected]>
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