microsoft / microsoft/durabletask-dotnet

Performance: avoid repeated protobuf sizing during orchestration response chunking

Open
#773 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Needs: Triage :mag:
Dominant language
C#
Stars
193
Forks
60
Avg merge
3d 12h
Merged PRs (30d)
4

Description

1. What is the issue?

The orchestration response chunking path can calculate protobuf action sizes multiple times: once for validation, once as part of whole-response sizing, and again while filling chunks.

2. Likely priority

Medium. The largest redundant portion is for workers without the LargePayloads capability; the chunking-specific repeat work occurs only for oversized responses. It is most visible with large payloads or many actions per orchestration turn.

3. Impact on performance

CalculateSize() walks the protobuf message graph, including serialized string payloads. Repeating it adds additional O(payload size x action count) CPU work to an orchestration completion, increasing replay-turn latency for fan-out responses.

4. Details and code reference

Relevant chunking implementation:

https://github.com/microsoft/durabletask-dotnet/blob/883211a3a7ab0b55bb90b9c9e498148e4d65ead9/src/Worker/Grpc/GrpcDurableTaskWorker.Processor.cs#L1096-L1210

The method validates every action with action.CalculateSize(), then invokes response.CalculateSize(), and TryAddAction calculates each action size again while constructing chunks.

5. Guidance for how to fix

Calculate the whole response size first. If it fits in one chunk, no individual action can exceed that same limit, so send it without an additional validation pass. When chunking is required, compute action sizes once and reuse the cached values for validation and chunk packing. Preserve the current oversized-single-action failure behavior when LargePayloads is unavailable, and add boundary tests around exact chunk limits and capability combinations.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in src/Worker/Grpc/GrpcDurableTaskWorker.Processor.cs around lines 1096-1210 and trace the response sizing and TryAddAction calls. Verify the current oversized-single-action behavior and add boundary tests for exact chunk limits and LargePayloads capability combinations. Done means redundant CalculateSize work is avoided while chunking and failure behavior remain unchanged.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, grpc
Domain
backend, distributed-systems, performance, testing
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.