Dify Community Reports OpenAPI Parameter Inheritance Bug; Custom Tools May Send Incorrect Paths

On September 26, the Dify community reported that importing an OpenAPI document for a custom tool omits shared parameters declared at the path level. The case came from a self-hosted source-code environment labeled 1.17.1 and included a main-branch commit reference and a minimal reproduction specification. The issue was still open at the time of review. [Issue report](https://github.com/langgenius/dify/issues/42994)

The example places `user_id` in the `parameters` for `/users/{user_id}`, rather than inside the GET operation. The report says the generated tool has no input field for it, and the request path retains the variable braces instead of substituting the provided value. When the specification is changed to Swagger 2.0 format, `parameters` is mistakenly treated as an operation, and the import is rejected because it lacks an `operationId`. [Reproduction details](https://github.com/langgenius/dify/issues/42994)

This declaration style conforms to the OpenAPI 3.0 specification: path-level parameters apply to all operations on that path. An operation can override a parameter, but cannot remove it. Determining whether two parameters are the same requires comparing both the name and location, so a fix cannot simply concatenate the two lists; it must also handle overrides and duplicates. [OpenAPI specification](https://spec.openapis.org/oas/v3.0.0.html#path-item-object)

An inspection of the Dify 1.17.1 parser shows that tool creation reads parameters only from each HTTP operation and does not first merge in path-level definitions. The Swagger conversion flow iterates over every key in the path object and directly requires each item to have an operation identifier. These two code paths are consistent with the report. [Version source code](https://github.com/langgenius/dify/blob/1.17.1/api/core/tools/utils/parser.py)

Dify’s official documentation explains that importing an OpenAPI specification automatically generates a tool interface for workflows and agents to call external services. Based on that, this bug could cause valid enterprise API definitions to lose required inputs when connected to an agent. Troubleshooting should check the fields produced by the conversion and the actual HTTP request, rather than only whether the model selected the correct tool. [Tools documentation](https://docs.dify.ai/en/cloud/use-dify/workspace/tools)

Engineering teams can first compare path-level and operation-level declarations using a test endpoint, checking that field generation and parameter substitution behave consistently. Specification-based regression cases should also cover parameters with the same name but different locations, as well as the type and required settings after an operation overrides a shared definition. If multiple tools use the same specification, validate each operation individually; a passing test for one endpoint does not establish that the entire definition is compatible.

The reporter says a fix and regression tests are available, but this review could not confirm whether they have been merged or released in an official version. The available evidence is also insufficient to establish all affected versions or cloud deployments. Follow-up should track maintainer confirmation, fix testing, and release records. [Issue status](https://github.com/langgenius/dify/issues/42994)