Actors: a call cancelled while it runs frees the turn in daprd while the method is still executing, so the next call overlaps (port of dapr/dotnet-sdk#1937)
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 47/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
调研方向
Start with ActorManager._dispatch_internal and trace how _on_pre_actor_method_internal, the actor method, and _on_post_actor_method_internal run for the same actor ID. Compare the proposed turn-lock behavior with the linked .NET ActorTurnLock and ActorManager; the issue describes the required cancellation and reentrancy cases. Done means actor turns stay serialized through state saving across HTTP and gRPC, including reminders, timers, and deactivation.
由索引模型根据 Issue 内容生成。
描述
Summary
When a caller cancels an actor call while it's running, daprd releases that actor's turn and starts the next queued call, but this SDK keeps running the cancelled call's actor method. Two turns then run on the same actor ID at once, which breaks turn-based concurrency. It happens with reentrancy off as well as on.
The runtime alone can't prevent this. The .NET SDK fixed it on its side in dapr/dotnet-sdk#1937 (released in Dapr.Actors 1.19.0) by holding the turn in the app. This SDK has no equivalent, as far as we can see.
How it happens
- daprd takes the actor's lock, calls the app with the caller's context, and releases the lock when that call returns (
app.InvokeMethod). - If the caller cancels, the call to the app returns at once and the lock is released, even though the app is still running the method:
- Over HTTP, daprd aborts the request.
- Over the gRPC actor callback stream, daprd stops waiting for the response and sends the app nothing (
callbackstream.go).
- daprd then sends the next queued call for that actor ID. Neither an aborted HTTP request nor an abandoned stream call stops the actor method, so it overlaps with the new call.
dapr/dapr#10835 reported the overlap. dapr/dapr#10842, in runtime 1.19.0, fixed a related case: a call cancelled while still queued no longer evicts the running turn. A cancelled running call still releases the turn early, because daprd can't know when the app finishes once it stops waiting.
Evidence
From the standalone reproduction. Each trial sends 20 calls × 2s to one actor ID, cancels them all at a fixed time, and counts in-progress turns inside the actor. Kubernetes (kind), .NET actor host:
| Runtime | .NET SDK | Reentrancy off | Reentrancy on |
|---|---|---|---|
| 1.18.7 | 1.18.10 | 8 of 12 trials overlapped (up to 7 turns at once) | 7 of 12 (up to 9) |
| 1.19.0 | 1.18.10 (no app-side lock) | 3 of 12 (up to 2) | 4 of 12 (up to 4) |
| 1.19.0 | 1.19.0 (with #1937) | 0 of 12 | 0 of 12 |
We measured this with the .NET SDK only and haven't run the reproduction against this SDK. The code below has no lock that would prevent it, though.
Where (python-sdk)
ActorManager._dispatch_internal holds _active_actors_lock only to look up the actor. _on_pre_actor_method_internal, the method and _on_post_actor_method_internal (the state save) run outside any per-actor lock. Two coroutines for the same actor ID can therefore interleave at any await, over both HTTP (FastAPI/Flask extensions) and the gRPC callback host (grpc_host.py).
Suggested fix
Port the .NET approach: a per-actor turn lock in the SDK (ActorTurnLock, acquired in ActorManager).
- Acquire it per actor ID before activation and the method call.
- Hold it until the actor code has finished, including the post-method state save, whether or not the request was cancelled.
- When reentrancy is enabled, let a call with the same non-empty reentrancy ID as the running turn enter.
- Apply it to reminders, timers and deactivation as well as method calls.
Its own comment states the rule: "The sidecar can stop waiting before actor code finishes. Keep local ownership until every invocation in the turn has completed, not until its request is cancelled."
- 主要语言
- Python
- 星标
- 274
- 派生
- 160
- 平均合并
- 2 天 2 小时
- 30 天内合并 PR
- 71
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
dapr/python-sdk 的其他 Issue
-
Add the OpenSSF Scorecard GitHub Action and publish the results可能已有人在做 @AdepuSriCharan 于 5 天前认领。 未关闭good first issue help wanted
难度 2/5 1-3 小时 新手友好度 78/100
dapr/python-sdk#1332 ·
维护者通常 2 天内回复
-
SDK Alignment of Workflow Examples可能重新可做 关联的 PR 已关闭且未合并。 未关闭dapr-ext-workflow good first issue kind/enhancement P2
难度 2/5 1-2 天 新手友好度 72/100
dapr/python-sdk#853 · 4 条评论 ·
维护者通常 2 天内回复
-
Add PyPI keywords and project links to the dapr package可能已有人在做 @SpinachDigital 于 6 天前认领。 未关闭good first issue help wanted kind/enhancement
难度 2/5 1-3 小时 新手友好度 20/100
dapr/python-sdk#1335 · 1 条评论 ·
维护者通常 2 天内回复
-
ci/release-failure release
难度 2/5 1-3 小时 新手友好度 25/100
dapr/python-sdk#1320 ·
维护者通常 2 天内回复
-
ci/release-failure release
难度 2/5 1-3 小时 新手友好度 49/100
dapr/python-sdk#1311 ·
维护者通常 2 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
btclib-org/btclib-wallet#587 · 1 条评论 ·
维护者通常 1 天内回复
-
documentation
难度 2/5 1-3 小时 新手友好度 68/100
Judgment-Pack/judgment-pack-spec#275 ·
维护者通常 1 天内回复
-
ai-generated
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
documentation good first issue priority: low size: XS
难度 1/5 1-3 小时 新手友好度 92/100
yeongseon/azure-functions-doctor-python#651 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
Changaco/python-libarchive-c#146 ·