fix(api): correct plugin dependency id format in snippet DSL extraction

[SquabbyZ]

Fixes #38406

Summary

In api/services/snippet_dsl_service.py:577 and :585, the tool and agent branches of _extract_dependencies_from_workflow_graph() both build the dependency id with:

dependencies.append(f"{provider_name}/{provider_name}")

That produces ids like google/google (the two halves of the f-string are the same variable) which never match a real plugin id. The docstring two lines above explicitly says the expected format is ['langgenius/google'] and the canonical plugin id format is {organization}/{plugin_name}, where organization == provider_type for non-langgenius tools and plugin_name == provider_name.

Introduced during the early Snippet DSL implementation; never fixed because the buggy ids were silently dropped downstream (check_dependencies would just report no leaked deps for the typo output, instead of detecting the actual missing plugin).

Changes

api/services/snippet_dsl_service.py: switch both f-strings from f"{provider_name}/{provider_name}" to f"{provider_type}/{provider_name}", which matches the docstring and analyze_tool_dependency()'s output in services/plugin/dependencies_analysis.py (which uses ToolProviderID(tool_id).plugin_id == '{organization}/{plugin_name}').

A regression test is added in api/tests/unit_tests/services/test_snippet_dsl_service.py:

• A graph with a TOOL node using provider='google' and an AGENT node using provider='openai' (both provider_type='langgenius') now extracts ['langgenius/google', 'langgenius/openai'].
• A TOOL node with only provider_type set (no provider) is correctly skipped instead of being appended as a malformed id.

Diff stat

api/services/snippet_dsl_service.py                       | 4 ++--
api/tests/unit_tests/services/test_snippet_dsl_service.py | 49 ++++++++++++++++++
2 files changed, 51 insertions(+), 2 deletions(-)

Test plan

• pytest api/tests/unit_tests/services/test_snippet_dsl_service.py::test_extract_dependencies_from_workflow_graph_uses_provider_type_and_name -v passes.
• All existing test_snippet_dsl_service.py tests continue to pass.
• Manual: export a workflow snippet that includes a Google search tool ??confirm the leaked-dependency check correctly reports langgenius/google as a dependency.
• ruff check api/services/snippet_dsl_service.py clean.

Risk / behavior preservation

• Only the string format of appended dependency ids is corrected. No other branch of the function is touched.
• The function still returns list[str] and is still called by the same two callers (_extract_dependencies_from_workflow at lines 393 and 534).
• The buggy output ('google/google') was always a no-op downstream ??it never matched any installed plugin, so the call sites already had no observation of the typo. The corrected output now matches real plugin ids, so any check_dependencies run that was silently passing may now surface legitimate missing-plugin warnings. This is the intended new behavior.
• No schema, migration, controller, or frontend changes.

Related

• Discovered by peaks-loop session 2026-07-02-session-95565c during a code-sweep on 2026-07-02.
• Companion function: DependenciesAnalysisService.analyze_tool_dependency in services/plugin/dependencies_analysis.py ??the canonical formatter that this PR brings the snippet path in line with.

Automation

Generated via peaks-loop (full-auto mode). Red-line scope was limited to snippet_dsl_service.py and the matching test file. Commit message includes the peaks-loop provenance line for traceability.

?? Generated with Claude Code via peaks-loop

[crazywoola]

Thanks for the contribution. Before we review this PR, please open an issue first to describe the problem, expected behavior, and proposed approach, then link that issue here. This helps us confirm the scope and align on the fix before moving forward.

[SquabbyZ]

@crazywoola Thanks for the guidance. Opened issue #38406 describing the malformed plugin id bug (f"{provider_name}/{provider_name}" instead of f"{provider_type}/{provider_name}"), the proposed fix, and the regression test. PR description now links the issue via Fixes #38406. Ready for re-review.