Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for refactors or chores; 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.

Description

GraphInitParams is currently acting as a pass-through container in the workflow stack. It carries a small set of values (workflow_id, graph_config, run_context, and call_depth), but Dify mostly constructs it at workflow entry points and then immediately fans those values back out through the node factory and node base classes.

This refactor should gradually remove direct reliance on GraphInitParams from the Dify workflow layer, then align the upstream graphon API, and finally delete the compatibility path once the new API is stable.

Proposed phased plan:

1. Phase 1: Dify-side reduction

   • Introduce a Dify-owned explicit graph init context.
   • Route Dify workflow entry points through that explicit context instead of constructing GraphInitParams directly at every production call site.
   • Remove direct read-back usages where code reaches into graph_init_params just to obtain values already exposed elsewhere.
   • Keep the current graphon API unchanged during this phase so the migration remains reviewable and safe.

2. Phase 2: graphon compatibility release

   • Update graphon node and child-engine APIs to accept explicit init values instead of a GraphInitParams object.
   • Keep a temporary adapter path for compatibility while downstream callers migrate.
   • Move nested workflow, loop, and iteration child-engine creation onto the new explicit API.

3. Phase 3: cleanup

   • Upgrade Dify to the new graphon API.
   • Remove the Dify compatibility bridge and remaining production references.
   • Delete obsolete helper paths and complete the final cleanup in tests.

This should be executed as a sequence of small, reviewable changes rather than a single graph-engine rewrite.

Motivation

Removing GraphInitParams will make ownership boundaries clearer and reduce the amount of bag-style context threading in the workflow stack.

It should also make future graph initialization and child-graph APIs easier to reason about, because callers will pass explicit values instead of relying on an object whose contents are immediately unpacked again.

Additional Context

Current direction for the migration:

• Keep behavior stable while reducing Dify-side coupling first.
• Avoid broad graph execution refactors until the explicit init path is established.
• Treat the graphon API change as a separate follow-up step so Dify and graphon can migrate in a controlled order.