Skip to content

Conversation variables updated in iteration do not persist in main flow #43312

Description

@GoHirosawa

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.17.1

Cloud or Self Hosted

Cloud, Self Hosted (Docker)

Steps to reproduce

  1. Create a conversation variable.
  2. Set a value for that conversation variable within an iteration node; the value is set correctly at this stage.
  3. Upon exiting the iteration node, the value of the conversation variable is cleared.

※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.

Activity

  1. Souravrajvi0 commented on Oct 1, 2026

    @Souravrajvi0
    Contributor

    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 IterationContainerHandler subclass and restores the table-driven regression test (update-conversation-variable-in-iteration fixture).

    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).

  2. Stream29 commented on Oct 9, 2026

    @Stream29
    Contributor

    Thank you for reporting this issue!

    Reproduced on Dify 1.17.1: a conversation variable updated inside an Iteration shows the new value there, but the parent flow still sees the old value. We'll be working on this.

    Screenshots:

    Image Image Image
  3. added a commit that references this issue on Oct 10, 2026
    24eda88
  4. Stream29 commented on Oct 11, 2026

    @Stream29
    Contributor

    @laipz8200 could you clarify whether conversation.* should be an exception to Iteration's variable isolation?

    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 c9b7a684 using 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:

    1. A serial Iteration copies conversation.a and conversation.b.
    2. Its child writes a; another parent-graph branch then writes b.
    3. 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?

  5. self-assigned this
    on Oct 12, 2026
  6. laipz8200 commented on Oct 12, 2026

    @laipz8200
    Member

    It seems a bug in GraphOn; I'll check and fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

review: lowghfind author score; see https://ghfind.com🐞 bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions