fix(worker): continue 命中挂起执行被终态化成不可恢复 error——可唤醒的挂起被一次重复投递毁成死局
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 68/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, distributed-systems
Research direction
Start with core/strategies.py:243-264 and flow_worker.py:868-881, 964-970, and 1021-1047 to trace how a continue message reaches a pending execution. Reproduce the suspended-execution redelivery scenario described in the issue, then verify that the run remains suspended and a later event wake-up succeeds.
Written by the indexing model from the issue text.
Description
场景 gap 单（okguitar 提报）· 优先级 P1 · 依赖：无
基线 HEAD = ddcedae。
Summary
core/strategies.py:243-264：挂起节点 pending 时，continue/retry 即抛ResumeError（防御本身正确——防绕过 pending 事件）。flow_worker.py:1021-1047resume 通用 except：_is_retryable_node_failure（:94-123）在异常链里找不到NodeExecutionError（ResumeError 无__cause__）→ 不重试 →state.status = "error"落盘 + raise → 消息重投命中终态短路被 ack。挂起执行就此翻成 error 终态。- 终态短路（:868-881）只放行
error + resume_type=retry；此后resume_type=event/cancel/timeout一律already_terminal。G1 retry 唤醒（:964-970）→ 再次命中 strategies 的 pending 守卫 → 再次 ResumeError → 再次 error——死循环，checkpoint 里的合法挂起状态永远无法被决议。
三个真实入口会把 continue 类消息送到挂起执行上：(a) 挂起双写窗口——_process_execution_result（:1125-1131）先 save(suspended) 再 _dispatch_service_task，两步之间 worker 崩溃，重投的原消息正是 continue；(b) start 重派竞速（见 start 双跑配套单）——重入队消息消费前执行恰好挂起；(c) 运维/上游误发。
影响
一次重复投递就把一个本可等审批/延迟/事件恢复的执行永久打封装进 error——连 resume_type=event 都进不去。keeper 场景下「随机某个挂起中的 run 无声死掉，retry 也救不回」。
建议
resume_flow 识别「非终态 + checkpoint 处于 pending 节点 + resume_type=continue」→ 幂等短路返回（或重派该节点的 service 任务）；至少把挂起守卫类 ResumeError 从「终态化 error」中豁免为「保持 suspended + ack」。
验收：构造 suspended 执行，投 continue 消息，断言状态仍 suspended 且后续 event 唤醒可成功。
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- Avg merge
- 2h 22m
- Merged PRs (30d)
- 8
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from jeffkit/plaita
-
fix(console): #274 并发同 dedup_key 双 POST 各自入队——预认领与占位行非原子，落败 id 永久 queued 且占配额Possibly taken @okguitar claimed this today. Open
Difficulty 5/5 Over a week Newbie friendliness 35/100
jeffkit/plaita#280 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
fix(console): ${redis.url} 从配置文件而非数据面 effective URL 解析——metadata 档 worker 静默连 localhost，warnings 为空Open
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Maintainers usually reply within 1 day
-
refactor(expr): 摘除运行期字符串的二次求值（#104/#130 的终章）——契约定为「配置求值、运行期数据」Possibly taken @jeffkit claimed this today. Open
Difficulty 5/5 Over a week Newbie friendliness 25/100
jeffkit/plaita#268 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
pgvector/pgvector-python#169 ·
-
ChaosEngine: backup-remote doctor row passes while consumer mode hides bot memory from gitPossibly taken @MohabMohie claimed this today. Openagentic
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
ShaftHQ/SHAFT_ENGINE#7263 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
huggingface/smolagents#3045 ·
Maintainers usually reply within 1 day