Selector or count rebuild after a sub-widget write replays differently by apply order

未关闭
  • 哪里不对？
#1,101 0 条评论 0 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@jaeone94 已经在做这个了。

开始于 2026年11月3日。

  • #1136 来自 @skishore23 —— 未关闭

评估

这个 Issue 还没有评估数据。

描述

A batch that writes a DynamicCombo sub-widget and then switches the selector away and back replays to different graphs depending on apply order.

On a Gen node already at model = max:

specs = [model.mode = quality, model = base, model = max]
  • Forward replay: the model = max rebuild refills model.mode with its default, so the node ends at balanced.
  • Reverse replay: model = max wins first and model = base loses the gate, so no rebuild happens. model.mode = quality still applies, so the node ends at quality.

The rebuild resets the sub-widget's value but leaves its _widget_stamps entry alone, so the earlier sub-widget write keeps winning its gate in one order and not the other. A DynamicGroup shrink-then-regrow in one batch has the same shape.

With #1007 the ops in a batch are minted in increasing order, so this shape diverges every time instead of depending on random op_ids. #1007 narrows its amendment's convergence claim and leaves this open.

Possible fixes: have a selector or count rebuild bump or reset the stamps of the sub-widgets it replaces, or refuse a batch that writes a sub-widget before rebuilding its selector or count.

Found by Cursor review on #1007.

主要语言
Python
星标
1k
派生
176
平均合并
1 天 11 小时
30 天内合并 PR
87

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

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

Comfy-Org/comfy-cli 的其他 Issue

查看 Comfy-Org/comfy-cli 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

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