Repository navigation
Conversation variables updated in iteration do not persist in main flow #43312
Description
Activity
- addedreview: lowghfind author score; see https://ghfind.comghfind author score; see https://ghfind.com
on Oct 1, 2026 Thanks for the clear repro — this is a legitimate regression, not a workflow misconfiguration.
What happened: The same behavior was fixed in #26367 via #26368 (syncing
conversation.*updates from iteration subgraphs back to the parent variable pool). When workflow execution moved into the Graphon package, that sync logic was not carried over, so values written inside an iteration are correct during the iteration but disappear once the frame completes.Fix in progress: #43329 reintroduces propagation via a Dify
IterationContainerHandlersubclass and restores the table-driven regression test (update-conversation-variable-in-iterationfixture).If you can still reproduce on 1.17.1 Cloud/Self-hosted, this PR should address it once merged and released. Parallel iteration + conversation variable writes remain a separate edge case (the UI already warns about that).
Reacted by go-hirosawa- added a commit that references this issue
on Oct 10, 2026 @laipz8200 could you clarify whether
conversation.*should be an exception to Iteration's variable isolation?- Dify fix(workflow): sync iteration conversation variables #26368 explicitly propagated conversation updates from Iteration back to the parent.
- Graphon #249 explicitly keeps Iteration frames isolated. Its regression test checks a Loop variable, not
conversation.*; that is a 0.8 design, while fix(workflow): sync conversation variables after iteration frames #43329 still uses 0.7.0.
Is the missing conversation write-back an integration gap, or an intended behavior change? If the exception should remain, should Dify implement it through a container handler, or should Graphon expose a shared-variable policy?
Separately, I checked #43329 at
c9b7a684using Graphon 0.7.0 with mocked Code nodes and real Iteration/Variable Assigner execution. It fixes the original fixture and serial accumulation, but the full conversation snapshot write-back also overwrites variables the child never changed:- A serial Iteration copies
conversation.aandconversation.b. - Its child writes
a; another parent-graph branch then writesb. - When the Iteration frame completes, its stale snapshot restores the old
b.
The persistence layer receives the new
b, but the final parent pool contains the old value; I verified the layer's updater calls, not an actual database write. This is not the same-variable race in parallel Iteration.Could we confirm the intended conversation scope before choosing the propagation behavior?
It seems a bug in GraphOn; I'll check and fix it.
Reacted by Stream





Self Checks
Dify version
1.17.1
Cloud or Self Hosted
Cloud, Self Hosted (Docker)
Steps to reproduce
※It appears that a past issue, such as "26367," is recurring.
✔️ Expected Behavior
The conversation variable should retain the value written inside the iteration, allowing the answer node to echo the incoming query.
❌ Actual Behavior
The conversation variable reverts to the previous value once the iteration finishes, so the downstream answer node produces an empty response.