Send raw history events from matching to frontend service #8829
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
Resolved conflicts: - service/history/api/recordworkflowtaskstarted/api.go: kept our return type, added main's GetActiveNamespace parameter - api/matchingservice/v1/request_response.pb.go: regenerated proto files 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Add //nolint:staticcheck comments to suppress SA1019 deprecation warnings for RawHistory field usage. These deprecated fields are intentionally used for backward compatibility during rolling upgrades. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
…sponseWithRawHistory
- Keep SendRawHistoryBetweenInternalServices default as false - TestQueryNoCurrentPollersButRecentPollers, TestQueryNoRecentPoller: Use emptyClientPollWorkflowTaskQueueResponse for mock client tests since client interface uses PollWorkflowTaskQueueResponse (not the WithRawHistory variant)
prathyushpv
changed the title
yycptt
reviewed
Jan 21, 2026
Member
yycptt
left a comment
yycptt
left a comment
There was a problem hiding this comment.
synced offline. I think we need a separate flag for this change or we will have a regression on the history service side (an extra decoding)
| // History client will deserialize this message to RecordWorkflowTaskStartedResponse. | ||
| // Deprecated: This field is being replaced by raw_history_bytes which sends raw bytes | ||
| // instead of a proto-decoded History. This avoids matching service having to decode history. | ||
| temporal.api.history.v1.History raw_history = 20 [deprecated = true]; |
Member
There was a problem hiding this comment.
plz add comment for the plan of deprecating related fields/messages.
| repeated bytes raw_history_bytes = 21; | ||
| } | ||
|
|
||
| // RecordWorkflowTaskStartedResponseWithRawHistory is wire-compatible with RecordWorkflowTaskStartedResponse. |
Member
There was a problem hiding this comment.
looks like this is no longer used and can be removed?
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?
This PR extends the raw history optimization to pass raw history bytes from History Service → Matching Service → Frontend without deserialization in Matching Service.
Key changes:
SendRawHistoryBetweenInternalServicesis enabled, setsRawHistoryBytes(field 21) with raw proto-encoded history batchesPollWorkflowTaskQueueResponseWithRawHistory[][]byte→Historyon the client sideRawHistoryfield (auto-deserialized by gRPC)raw_history_bytes(field 21) toRecordWorkflowTaskStartedResponsePollWorkflowTaskQueueResponseWithRawHistorymessage with wire-compatible layoutraw_history(field 22) toPollWorkflowTaskQueueResponseWhy?
When
history.sendRawHistoryBetweenInternalServicesis enabled, the previous implementation only avoided deserialization from persistence → History Service. However, Matching Service was still deserializing history events (via gRPC auto-deserialization) and re-serializing them when forwarding to Frontend.This change eliminates that unnecessary serialization/deserialization cycle in Matching Service by:
This reduces CPU usage in Matching Service for workflows with large histories.
How did you test it?
tests/workflow_task_test.go)Potential risks
SendRawHistoryBetweenInternalServices must be disabled when rolling back from this version to an older version.