microsoft / microsoft/durabletask-python
Consider lazy durable entity state serialization semantics
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 40
- フォーク
- 33
- 平均マージ
- 2日 2時間
- マージ済み PR(30日)
- 6
説明
Summary
Durable entity state is currently serialized eagerly when set_state() is called. This snapshots the value immediately, so mutations made to the same Python object after set_state() do not affect the state eventually persisted at the end of the operation.
state = Point(1)
self.set_state(state)
state.value = 99
The persisted state is Point(1), not Point(99).
This may surprise Python users who expect ordinary reference semantics and could introduce subtle bugs when entity code mutates an object after passing it to set_state().
Scope
The behavior is implemented in the core durabletask entity StateShim, so it affects core durabletask entities and providers built on it, including durabletask-azuremanaged and azure-functions-durable.
Current rationale
Eager serialization was introduced intentionally to:
- surface serialization errors inside the operation that called
set_state(); - preserve per-operation rollback behavior in an entity batch;
- retain the original serialized wire payload when state is unmodified; and
- prevent mutations to values returned by
get_state()from implicitly changing persisted state without a correspondingset_state().
Design question
Should set_state() retain the live value and defer serialization until successful operation completion, so mutations made after set_state() but before the operation returns are persisted?
If so, the design needs to define:
- whether
get_state()afterset_state()returns the same pending live object or a reconstructed copy; - where serialization occurs so serialization failures still fail and roll back the current operation;
- behavior across multiple operations in one entity batch;
- compatibility implications of changing
set_state()from snapshot-at-call semantics to retain-reference-until-commit semantics; and - consistency with Durable Entity semantics in other language SDKs.
Suggested investigation
- Compare mutation semantics with other Durable Entity SDKs.
- Prototype deferred serialization at the operation commit boundary.
- Add tests for post-
set_state()mutation, serialization failure, rollback, deletion, unmodified wire payloads, and multiple operations in one batch. - Document the current requirement to perform mutations before the final
set_state()call unless the behavior changes.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
中核となる Durable Task エンティティ StateShim から始め、set_state()、get_state()、操作の完了、ロールバック、削除が現在シリアライズ済みの状態をどのように扱っているかを追跡します。遅延シリアライズが適切かどうかを判断する前に、他の Durable Entity SDKs とミューテーションのセマンティクスを比較します。set_state 後のミューテーション、シリアライズ失敗、ロールバック、削除、変更されていない wire payloads、および1つの batch 内での複数の操作についてカバレッジを追加します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- backend
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 静か
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 30/100