Parameter pass-through

[kingWYZ]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

How to access the custom parameters from the docker-api-1 container in docker-worker-1, similar to global variables

[dosubot[bot]]

To pass custom parameters from the API container to the worker container in Dify, use the extra_context parameter in build_dify_run_context():

In the API container:

run_context = build_dify_run_context(
    tenant_id=...,
    app_id=...,
    user_id=...,
    user_from=UserFrom.ACCOUNT,
    invoke_from=InvokeFrom.DEBUGGER,
    extra_context={"organization": organization, "user": user_param}
)

In worker container nodes:

organization = self.get_run_context_value("organization")
user = self.get_run_context_value("user")

Important notes:

• Flask's current_app doesn't work in Celery workers since they run outside Flask's application context - you must explicitly pass parameters through extra_context
• The build_dify_run_context() function with extra_context support was introduced on March 5, 2026 - if you're on an older version (like v1.13.0), this mechanism won't be available
• After code changes, rebuild and restart the worker container since it uses a pre-built image

There's also a related discussion with the same question that might be helpful.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[dosubot[bot]]

The parameters need to be threaded through several layers. Here's the complete path:

Step 1: Add parameters to the Pydantic model in workflow.py:

class DraftWorkflowRunPayload(BaseWorkflowRunPayload):
    inputs: dict[str, Any]
    organization: str | None = None
    user: str | None = None

Step 2: Extract and pass in the endpoint handler - include them in the args dict that gets passed to AppGenerateService.

Step 3: Store in WorkflowAppGenerateEntity.extras in app_generator.py. The codebase already uses extras for external_trace_id, so you can follow the same pattern:

extras = {}
if args.get("organization"):
    extras["organization"] = args["organization"]
if args.get("user"):
    extras["user"] = args["user"]

Step 4: Pass to build_dify_run_context in workflow_app_runner.py:

run_context = build_dify_run_context(
    tenant_id=tenant_id or "",
    app_id=self._app_id,
    user_id=user_id,
    user_from=user_from,
    invoke_from=invoke_from,
    extra_context={
        "organization": self.application_generate_entity.extras.get("organization"),
        "user": self.application_generate_entity.extras.get("user"),
    }
)

The key insight is that build_dify_run_context already has the extra_context parameter designed for this purpose - you just need to wire up the data flow from the API layer to where it's called.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kingWYZ]

When I want to get these two values from the fetch_external_knowledge_retrieval function, what should I do, and please confirm whether self.application_generate_entity.extras.get("organization") is used correctly.

[dosubot[bot]]

Good question - there's an issue with the approach I outlined. self.application_generate_entity.extras is NOT accessible in workflow_app_runner.py because that attribute doesn't exist in that context.

To get your custom parameters into fetch_external_knowledge_retrieval, you need to thread them through the entire call chain:

1. In KnowledgeRetrievalNode (knowledge_retrieval_node.py), access the run context:

# Your custom params should be in extra_context
organization = self.get_run_context_value("organization")
user = self.get_run_context_value("user")

2. Pass them through DatasetRetrieval.knowledge_retrieval (dataset_retrieval.py) - you'll need to modify this method to accept and pass your custom parameters.

3. Add them to fetch_external_knowledge_retrieval signature (external_knowledge_service.py):

@staticmethod
def fetch_external_knowledge_retrieval(
    tenant_id: str,
    dataset_id: str,
    query: str,
    external_retrieval_parameters: dict,
    metadata_condition: MetadataCondition | None = None,
    organization: str | None = None,  # Add
    user: str | None = None,          # Add
):

The key insight is that extra_context values passed to build_dify_run_context become accessible via self.get_run_context_value("key") in workflow nodes - but you still need to manually propagate them through the DatasetRetrieval and ExternalDatasetService call chain since those aren't automatically passed.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[kingWYZ]

In version 1.13.0, there is no function get_run_context_value, so how do you obtain the context parameter values?

[dosubot[bot]]

You're right - get_run_context_value() was introduced after v1.13.0 (released February 11, 2026). In v1.13.0, you need to use the VariablePool pattern instead:

# In KnowledgeRetrievalNode or other workflow nodes
user_inputs = self.graph_runtime_state.variable_pool.user_inputs
organization = user_inputs.get("organization")
user = user_inputs.get("user")

Important caveat: In v1.13.0, user_inputs contains only what's in the workflow's inputs dict - peer-level API parameters don't automatically flow through. So your custom organization and user parameters must be added inside the inputs field of your request payload rather than as sibling fields:

{
  "inputs": {
    "organization": "your-org",
    "user": "your-user",
    "...other workflow inputs..."
  }
}

If you need them as separate API fields, you'll need to modify the API endpoint code to inject them into inputs before processing.

There's also a related discussion (#34007) covering the same v1.13.0 limitation that might be helpful.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}