Tool plugin dynamic-select dropdown does not fire _fetch_parameter_options on Cloud 1.14.1 (regression from 1.6.0)

[ShuntaroOkuma]

Self Checks

• This is only for bug report.
• I have searched for existing issues including closed ones. Closest match is In the TOOL plugin, the dynamic-select type always loses data on the orchestration page. #22147 — the title and the merged fix PR retention of data filled on tab switch for tool plugin #23323 only address the "data lost on tab switch" half of that thread; a separate symptom reported by @gao-xiangyang on 2025-07-12 inside the same thread ("After Dify was upgraded to version 1.6.0, the dynamic-select was not triggered") was never addressed. This issue is a focused report of that second symptom, reproduced on Cloud 1.14.1 (2026-05-22).
• I confirm that I am using English to submit this report.
• [FOR CHINESE USERS] N/A
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.14.1 (Cloud — confirmed via GET https://cloud.dify.ai/console/api/version?current_version=1.0.0).
Self-hosted not yet tested for this specific symptom — happy to add if requested.

Cloud or Self Hosted

Cloud

Steps to reproduce

A Tool plugin parameter declared as type: dynamic-select should populate its dropdown by Dify calling the plugin's _fetch_parameter_options(<parameter_name>) hook when the dropdown is opened. On Cloud, that call never happens: opening the dropdown produces no network request from the browser, no daemon log entry, and no traffic to the plugin runtime. The dropdown stays empty forever.

Minimum reproduction (YAML + Python, both excerpted from a Tool plugin we shipped — full history at ShuntaroOkuma/convoprobe-plugin commit 42528f5^):

tools/<tool>.yaml:

identity:
  author: <author>
  name: run_scenario
  label:
    en_US: Run Scenario

extra:
  python:
    source: tools/run_scenario.py

parameters:
  - name: scenario_id
    type: dynamic-select          # <-- the dropdown that never fires
    form: form
    required: true
    label:
      en_US: Scenario
    human_description:
      en_US: Select a scenario you have created in ConvoProbe Web UI.
    llm_description: ConvoProbe scenario identifier (UUID).

tools/<tool>.py:

from dify_plugin import Tool
from dify_plugin.entities import I18nObject, ParameterOption

class RunScenarioTool(Tool):
    def _fetch_parameter_options(self, parameter: str) -> list[ParameterOption]:
        # This method is never called by Dify Cloud 1.14.1 when the user
        # opens the `scenario_id` dropdown in the workflow node editor.
        # Returning a fixed list here for the simplest repro:
        return [
            ParameterOption(value="A", label=I18nObject(en_US="Scenario A")),
            ParameterOption(value="B", label=I18nObject(en_US="Scenario B")),
        ]

Steps:

1. Build the above as a .difypkg (or use Remote Debug).
2. Install on Dify Cloud, add it to a workflow node.
3. Open the node and click the Scenario dropdown.
4. Observe: the dropdown shows no options, no spinner. Browser DevTools shows zero network requests. Plugin process (in Remote Debug mode) shows no incoming call.

For our plugin specifically the live confirmation came from:

• Backend logs at https://convoprobe-production.up.railway.app during the dropdown click: zero hits to the corresponding /api/internal/plugin/scenarios endpoint that _fetch_parameter_options proxies to.
• Plugin process running INSTALL_METHOD=remote against debug.dify.ai:5003: zero received dispatches when the dropdown is opened. The TCP connection itself is healthy and the plugin is fine with other operations.

✔️ Expected Behavior

Same behavior as Dify 1.5.1 (per #22147 screenshots from 2025-07-12): opening a dynamic-select dropdown triggers Dify api → plugin daemon → plugin runtime → _fetch_parameter_options(<param>), the returned ParameterOption[] populates the dropdown.

❌ Actual Behavior

Opening the dropdown is a no-op. The hook is never invoked. The dropdown stays empty. The user has no way to know the failure mode without checking three layers (browser network panel, plugin daemon logs, plugin process stderr).

Why this matters

dynamic-select is the standard mechanism for any Tool plugin whose parameter values come from the plugin's own external API (saved scenarios, projects, channels, datasets, lists of records, etc.). With it broken on Cloud, all such plugins must currently fall back to a free-text input (the workaround we shipped in commit 42528f5 — type: string with a human "paste a UUID" instruction), which:

• destroys UX (users must copy a UUID from a web page and paste it),
• destroys discoverability (no list of available values),
• destroys validation (typos surface only at run time, deep in the plugin),
• and forces the plugin author to ship docs explaining how to find the value out-of-band.

Additional context

• The related thread In the TOOL plugin, the dynamic-select type always loses data on the orchestration page. #22147 already reported this same symptom in a comment dated 2025-07-12 but the fix PR (retention of data filled on tab switch for tool plugin #23323) only changed web/app/components/workflow/nodes/_base/components/variable/var-reference-picker.tsx and addressed the "selected value is lost when switching tabs" half. The "dropdown never fires" half was never touched.
• I would like to be assigned to this issue and attempt the fix PR myself (per CONTRIBUTING.md: "Before you draft a PR, please create an issue to discuss the changes you want to make"). Best guess so far: the workflow node editor's React component that mounts dynamic-select dropdowns may have lost the onOpen → fetchOptions wiring in the 1.6.0 refactor — would appreciate a pointer to the right file from anyone who already knows the area.
• Public reproduction code (with full git history of the dynamic-select implementation before we had to remove it): https://github.com/ShuntaroOkuma/convoprobe-plugin — see commit 42528f5 and its parent for the working _fetch_parameter_options implementation and the YAML.

[dosubot]

Hi @ShuntaroOkuma! I'm Dosu and I’m helping the dify team.

Thanks for the detailed reproduction and analysis, @ShuntaroOkuma. I dug into the current codebase to trace the dynamic-select flow and can share some pointers that should help your fix PR.

Current architecture (post-1.6.0 refactor): The dynamic-select fetch is no longer triggered on dropdown open. It was changed to eager loading on component mount via a useEffect in form-input-item.tsx. The effect runs when the component mounts with these guards:

if (isDynamicSelect && currentTool && currentProvider && 
    (providerType === PluginCategoryEnum.tool || providerType === PluginCategoryEnum.trigger))

The fetch itself uses a mutation hook (useFetchDynamicOptions) that calls GET /workspaces/current/plugin/parameters/dynamic-options with params including plugin_id, provider, action, and parameter [1].

Where to look for the bug:

1. plugin_id may be empty/missing for your plugin's collection. The code falls back to currentProvider?.plugin_id || '' [2], and plugin_id is an optional field on the Collection type [3]. If the backend isn't populating plugin_id for your plugin's tool collection, the API call fires with an empty string—which would likely return an error or empty result silently. Multiple PRs in late 2025/early 2026 fixed plugin_id and provider_id mismatches (PR #33182, PR #30374).

2. currentTool or currentProvider might be undefined at mount time. Both are resolved asynchronously via useCurrentToolCollection [4]. If the tool collection data hasn't loaded when the component first mounts and the useEffect deps don't properly re-trigger, the fetch never fires.

3. The key file for your fix is web/app/components/workflow/nodes/_base/components/form-input-item.tsx. The useEffect dependency array includes fetchDynamicOptions (the mutation function reference)—if this reference is unstable (recreated each render), it could cause the effect to fire before currentTool/currentProvider are populated, then not re-fire when they become available.

Quick debugging suggestion: In Remote Debug mode, add a console.log at the top of the useEffect (line 146) to print isDynamicSelect, currentTool?.name, currentProvider?.name, currentProvider?.plugin_id, and providerType. This will immediately tell you which guard condition is failing.

Re: your hypothesis about missing onOpen wiring: You're correct that there's no onOpen/onOpenChange handler on the Select component anymore [5]. The architectural decision in 1.6.0 was to move to eager loading. But if the eager loading fails silently (which appears to be your case), there's no fallback. Restoring a lazy-load trigger on onOpenChange as a fallback/retry mechanism would be a reasonable fix approach.

Related precedent: PR #23323 addressed the "selected value disappears during loading" half of #22147 but didn't address the "fetch never fires" scenario you're seeing. Your issue appears distinct from what that PR fixed.

Good luck with the fix—the scope is well-contained in form-input-item.tsx and the useFetchDynamicOptions hook.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[ShuntaroOkuma]

Update with the root-cause investigation results. The bug splits cleanly into two issues in two repos that combine to break Tool plugin dynamic-select end-to-end. Both reproduce on a fresh local docker-compose Dify 1.14.2 with langgenius/dify-plugin-daemon:0.6.1-local.

Bug 1 — langgenius/dify web, panel.tsx: currentProvider/currentTool not passed to the second <ToolForm>

In web/app/components/workflow/nodes/tool/panel.tsx, <ToolForm> is rendered twice — once for toolInputVarSchema (form: 'llm' params) and once for toolSettingSchema (form: 'form' params). The first call passes currentProvider={currCollection} and currentTool={currTool}, the second call does not:

// First ToolForm — passes both
<ToolForm
  ...
  currentProvider={currCollection}
  currentTool={currTool}
/>

// Second ToolForm — DOES NOT pass either
<ToolForm
  ...
  schema={toolSettingSchema as any}
  value={toolSettingValue}
  onChange={setToolSettingValue}
  // currentProvider / currentTool missing
/>

The form: 'form' | 'llm' split is done in hooks/use-config.ts:

const toolInputVarSchema = useMemo(
  () => formSchemas.filter((item: any) => item.form === 'llm'),  // LLM-decided
  [formSchemas],
)
const toolSettingSchema = useMemo(
  () => formSchemas.filter((item: any) => item.form !== 'llm'),  // user-set in node UI
  [formSchemas],
)

form: 'form' is the typical case for parameters the workflow author sets once in the node UI — i.e., almost every realistic dynamic-select parameter ends up in toolSettingSchema and renders via the broken second call. With currentProvider/currentTool undefined, the useEffect guard in form-input-item.tsx/var-reference-picker.tsx falls through silently, and _fetch_parameter_options never fires.

Fix (two lines):

                 <ToolForm
                   readOnly={readOnly}
                   nodeId={id}
                   schema={toolSettingSchema as any}
                   value={toolSettingValue}
                   onChange={setToolSettingValue}
+                  currentProvider={currCollection}
+                  currentTool={currTool}
                 />

I verified locally: with this patch, the _fetch_parameter_options API request fires correctly with provider_type=tool and the expected plugin_id/provider/action/parameter params. Which uncovers Bug 2 immediately below.

Bug 2 — langgenius/dify-plugin-sdks trigger_factory.py: get_trigger_event_handler_safely doesn't honor its name

Even with Bug 1 fixed, the API call returns 400:

{"code":"plugin_error","message":"{\"args\":{},\"error_type\":\"ValueError\",\"message\":\"Trigger provider `convoprobe` not found\"}"}

Stack trace from the plugin runtime stderr:

File ".../dify_plugin/core/plugin_executor.py", line 788, in _get_dynamic_parameter_action
    trigger_event: Event | None = self.registration.try_get_trigger_event_handler(
File ".../dify_plugin/core/plugin_registration.py", line 615, in try_get_trigger_event_handler
    return self.trigger_factory.get_trigger_event_handler_safely(...)
File ".../dify_plugin/core/trigger_factory.py", line 160, in get_trigger_event_handler_safely
    entry = self._get_entry(provider_name)
File ".../dify_plugin/core/trigger_factory.py", line 206, in _get_entry
    raise ValueError(msg) from exc
ValueError: Trigger provider `convoprobe` not found

plugin_executor._get_dynamic_parameter_action is supposed to try trigger first, then fall back to tool (source):

trigger_event = self.registration.try_get_trigger_event_handler(...)
if trigger_event is not None:
    return trigger_event

# fall back to tool
tool_cls = self.registration.get_tool_cls(provider=data.provider, tool=data.provider_action)
if tool_cls is not None:
    return tool_cls(...)

But try_get_trigger_event_handler → get_trigger_event_handler_safely → _get_entry and _get_entry raises ValueError("Trigger provider X not found") instead of returning None. So the "try trigger, fall back to tool" chain breaks on the first call for any tool plugin (which obviously isn't registered as a trigger). Tested in dify_plugin SDK 0.9.0 (latest).

Fix (dify_plugin/core/trigger_factory.py:157-164):

 def get_trigger_event_handler_safely(
     self, provider_name: str, event: str, runtime: EventRuntime
 ) -> Event | None:
-    entry = self._get_entry(provider_name)
+    try:
+        entry = self._get_entry(provider_name)
+    except ValueError:
+        return None
     if event not in entry.events:
         return None
     _, event_cls = entry.events[event]
     return event_cls(runtime)

This is in a separate repo (langgenius/dify-plugin-sdks). A fix has actually been waiting in PR langgenius/dify-plugin-sdks#281 (Jan 2026, "fix: handle exception in dynamic select options when trigger is not registered", closes issue #280). An earlier independent fix is in #261 (Dec 2025). Both are still OPEN, no human reviewer feedback. I'll comment over there with this reproduction and ask for review attention — but per CONTRIBUTING ("do not open duplicate issues or parallel pull requests for the same change") I won't open a third.

End-to-end verification (both fixes applied)

Local docker-compose Dify 1.14.2 + monkey-patched SDK on the plugin process:

• API call: GET /workspaces/current/plugin/parameters/dynamic-options?plugin_id=soitto%2Fconvoprobe&provider=soitto%2Fconvoprobe%2Fconvoprobe&action=run_scenario&parameter=scenario_id&provider_type=tool → 200 OK, 58 options
• Plugin runtime stderr: _fetch_parameter_options CALLED parameter='scenario_id' → returning 58 options
• Browser dropdown: populated with the expected scenario list.

Plan

Per CONTRIBUTING.md and the PR template ("Ensure there is an associated issue and you have been assigned to it"), I'd like to be assigned to this issue so I can submit the Bug 1 fix PR to langgenius/dify. PR scope will be tight: only the two added lines in panel.tsx. Happy to add a regression test if there's a recommended location for tool/panel.tsx tests — pointers welcome.

For Bug 2 in the SDK, I'll bump the existing #281 (and / or #261) with this reproduction. Both Bug 1 and Bug 2 need to land for Tool plugin dynamic-select to work end-to-end.