microsoft / microsoft/durabletask-python

Consider lazy durable entity state serialization semantics

未关闭
#234 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

主要语言
Python
星标
40
派生
33
平均合并
2 天 2 小时
30 天内合并 PR
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 corresponding set_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() after set_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.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

调研方向

从核心 Durable Task 实体 StateShim 开始,跟踪 set_state()、get_state()、操作完成、回滚和删除目前如何处理序列化状态。在决定是否适合延迟序列化之前,将 mutation 语义与其他 Durable Entity SDKs 进行比较。为 set_state 后的 mutation、序列化失败、回滚、删除、未更改的 wire payload 以及一个 batch 中的多个操作添加覆盖。

由索引模型根据 Issue 内容生成。

评估

技术栈
python
领域
backend
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
冷清
描述清晰度
需要澄清
新手友好度
30/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。