Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Clarify DataConverter vs PayloadConverter in data-handling docs for core-based SDKs

クローズ
  • 何か問題がありますか？
#86 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
78/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
csharp, python, typescript
領域
documentation

調査の方向性

references/dotnet/data-handling.md、references/python/data-handling.md、references/typescript/data-handling.md の Overview と default converter セクションから始めます。これらの用語と例を変更されていない Go および Java ファイルと比較し、その後、更新された各ファイルが三層モデルを説明し、Go/Java の違いを含み、対象外のファイルを変更せずに残していることを確認します。

索引モデルが issue の本文から書いたものです。

説明

Background

The current data-handling.md overviews in references/dotnet, references/python, and references/typescript treat "data converter" and "payload converter" as if they were the same thing. For example:

"The .NET SDK uses data converters to serialize/deserialize workflow inputs, outputs, and activity parameters."

This is technically imprecise for the core-based SDKs (.NET, Python, TypeScript, Ruby, Rust), where a DataConverter is a composite of three sub-components:

  • PayloadConverter — converts values ↔ bytes (this is what actually performs serialization)
  • PayloadCodec — bytes ↔ bytes transformation (e.g. encryption, compression)
  • FailureConverter — converts exceptions ↔ serialized failures

This is distinct from Go and Java, where DataConverter is the serialization interface (methods like ToPayload/FromPayload). In those SDKs, DataConverter plays the role that PayloadConverter plays in the core-based SDKs, and codecs are layered separately via CodecDataConverter.

Because developers (and AI skills using these docs) naturally assume "data conversion" works identically across SDKs, the current framing causes confusion. The Go and Java overviews are already accurate; the three core-based SDKs need updates.

See reviewer context: https://github.com/temporalio/skill-temporal-developer/pull/39#discussion_r... and the canonical description in https://github.com/temporalio/sdk-dotnet?tab=readme-ov-file#data-conversion.

Scope

Update these three files, applying the same depth of treatment to each:

  • references/dotnet/data-handling.md
  • references/python/data-handling.md
  • references/typescript/data-handling.md

Do not change references/go/data-handling.md or references/java/data-handling.md — their current framing is accurate for those SDKs.

Detailed changes per file

For each of the three files above:

1. Rewrite the Overview section

Introduce the three-layer model explicitly. Suggested structure:

The SDK uses a DataConverter to move values between the SDK and the Temporal Service. A DataConverter is a composite of three sub-components:

  • PayloadConverter — serializes values to/from Payload bytes (the default handles null, byte arrays, Protobuf messages, and JSON-serializable types).
  • PayloadCodec — transforms payload bytes (e.g. for encryption or compression).
  • FailureConverter — serializes exceptions/errors to/from Temporal Failure protobufs.

Most customization happens at the PayloadConverter layer. Encryption and compression belong in a PayloadCodec. Custom exception serialization belongs in a FailureConverter.

Adjust wording per-SDK to match idiomatic terms (e.g., Python uses failure_converter, TypeScript uses failureConverter, .NET uses FailureConverter).

2. Rename "Default Data Converter" → "Default Payload Converter"

The existing section that lists supported types (null, byte[], Protobuf, JSON, etc.) is describing what the default payload converter supports, not the DataConverter as a whole. Rename the section and adjust the leading sentence accordingly.

3. Review code examples

Make sure customization examples show the three-layer structure clearly — e.g., that overriding serialization means replacing the PayloadConverter inside DataConverter.Default, not replacing the DataConverter itself. (The current .NET example is already correct here; verify Python and TypeScript.)

4. Cross-reference

Add a short note in each updated overview that Go and Java use a different model (their DataConverter is the serialization interface) so readers don't transfer assumptions. One sentence is enough; avoid going into detail.

Out of scope

  • Go and Java data-handling.md files.
  • Changes to the actual SDK code or sample repos.
  • The core/data-handling.md file (if it exists) — to be reviewed separately.

Acceptance criteria

  • Overviews in .NET, Python, and TypeScript data-handling.md files describe DataConverter as the three-layer composite, with PayloadConverter identified as the serialization layer.
  • "Default Data Converter" → "Default Payload Converter" rename applied where the section describes payload-type support.
  • Each of the three files has a one-line note that Go/Java use a different model.
  • Go and Java files are unchanged.
  • Code examples remain accurate and compile-ready.
主要言語
言語のデータがありません
スター
230
フォーク
31
平均マージ
2日 6時間
マージ済み PR（30日）
22

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

temporalio/skill-temporal-developer のほかの issue

temporalio/skill-temporal-developer の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。