fix(worker): flow_hash 基于解析后 model_dump——版本演进使 hash 漂移，滚动升级把在途 run 批量终态化；worker 版本不可观测
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- backend, distributed-systems, observability
Research direction
Start with _compute_flow_hash and resume handling in flow_worker.py:512-525 and 937-954, then inspect worker registration at 1351-1356 and PLAITA_PYTHON handling in service_manager.py:159-162. Trace ExecutionState and the console service page before defining compatible version metadata, distinct mismatch reporting, and coverage for rolling-upgrade recovery. Done means the behavior is tested and worker versions are visible to operators.
Written by the indexing model from the issue text.
Description
场景 gap 单（okguitar 提报）· 优先级 P1 · 依赖：无
基线 HEAD = ddcedae。
Summary
_compute_flow_hash（flow_worker.py:512-525）对Flow.model_validate之后的对象做model_dump(mode="json")+sha256——docstring 自认「同一 pydantic 版本下字段序稳定」，反解读即跨 pydantic/plaita 版本不保证稳定。plaita 任何一次给 Node/Flow 增删序列化字段（哪怕带默认值）都会让同一份存储定义算出不同 hash。- resume 时
stored != current→ 终态化 error + poison ack（:937-954），无版本维度豁免。 - 版本漂移面真实：console 用
PLAITA_PYTHON给 worker 指定业务 venv 解释器（service_manager.py:159-162），worker 可跑与 console 不同的 plaita 版本；worker 注册元数据只有 queue/redis/cache 项（flow_worker.py:1351-1356），无 plaita/节点包版本号，console 服务页无法辨识新旧 worker。
影响
混部舰队（滚动升级窗口、venv 未同步）下：旧 worker start 写 hash A → 崩溃/重投后新 worker resume 算出 hash B → 在途 run 批量终态化 error，且文档的处置「修复定义后 retry」对此无效——定义没被改，改的是解读代码。旧版本 worker 的存在完全不可观测。
建议
hash 改算原始存储定义 JSON（model_validate 之前），对模型演进天然稳定；ExecutionState 增加 engine_version（start 时写入），hash 不匹配但 engine_version 变化时给可区分的 error 类别与指标；worker 注册元数据带 plaita __version__，console 服务页展示并支持最低版本告警。
- 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
-
Uninstall guide omits the CloudWatch log groups AWS CodeBuild creates for useCodeBuild pipelinesOpenbug documentation
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
awslabs/visual-asset-management-system#552 ·
Maintainers usually reply within 1 day
-
netbox status: needs triage type: documentation
Difficulty 1/5 Under an hour Newbie friendliness 76/100
netbox-community/netbox#23460 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
awslabs/threat-composer#362 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ansys/pyansys-common-mcp#213 ·
Maintainers usually reply within 3 days