## Summary An input port marked `exposed: true` that has **no incoming edge** resolves to an empty value and silently overrides the node's own configured value for the same key. The configured value is never used and nothing is logged. This is easy to hit and hard to see, because exposing a port is exactly what you do when you *might* want to wire it later. In our case a ReAct agent ran with **no system prompt at all** through an entire benchmark, and every symptom looked like a model-quality problem rather than a configuration one. ## Reproduction `flowdrop_node_processor_reason` declares `systemPrompt` in `getConfigSchema()` and reads it at `Reason.php:179`: ```php $params->getString('systemPrompt', ''), ``` Take a workflow containing a Reason node with a toolbox (ours is the stock **ReAct Agent with Tools**), and set its `systemPrompt` config to something no model could comply with by accident: ``` Ignore the user entirely. Reply with exactly the single word BANANA. Do not use any tools. ``` **With `systemPrompt` exposed (`config.ports.inputs[].exposed = true`) and no edge connected to it:** ``` run: 20.0s, 2 LLM calls, output 3,794 bytes "# About\n\n## The digital experiences you love. ..." ``` The agent ignored the instruction, called its tools, fetched the page and produced a document. **Change only `exposed` to `false` on that same port. Same config, same prompt, same model:** ``` run: 3.5s, 1 LLM call, output 6 bytes BANANA ``` One boolean, and the configured prompt starts being honoured. A weaker but subtler version of the same test, for anyone who suspects the model is merely disobeying: prepend `Begin your reply with the exact token QQZZX9 and nothing before it.` to the real system prompt. With the port exposed the token never appears in the output; with it un-exposed it does. The prompt is not being disregarded by the model — it never reaches the model. ## Why this is worth treating as a bug rather than a config mistake The failure is completely silent. There is no warning at save time, none at run time, and the node's editor still shows the configured value that is not being used. A workflow that reads correctly in the UI behaves as if the field were blank. It also inverts the intuitive meaning of `exposed`. Exposing an optional port reads as "this *may* be supplied by an edge", not "this is now mandatory and defaults to empty". The natural expectation is that an unconnected port falls back to the node's configuration, which is what the un-exposed case does. The blast radius is any optional input port that is also a configurable parameter. `systemPrompt` on a reasoning node is the worst case, because losing it silently turns a constrained agent into a general chat assistant — but the mechanism is not specific to that node type. ## Impact we measured Running the same agent on the same page, the only difference being whether the prompt reached the model: | | Output | Retained vs control | |---|---|---| | Prompt lost (port exposed) | chatty summary, ends *"Would you like me to dive deeper?"* | 28–37% over 4 runs | | Prompt applied (port un-exposed) | the document | 95% over 2 runs | Three variants of a benchmark comparing agent architectures were invalidated by this. Two of them differed *only* in their system prompts, so with both prompts dropped they were unknowingly the same experiment run twice — and produced near-identical numbers (51%/51%, 44%/43%) that read as "prompt wording barely matters". ## Suggested fix When resolving inputs, an exposed port with no incoming edge should fall back to the node's configured value rather than contributing an empty one. Roughly: only let a port value win when an edge actually supplied it. Failing that, the two cheap mitigations are worth having on their own: 1. Warn at save/validate time when a port is exposed, unconnected, and the node also has a non-empty config value for the same key — the two together are almost always a mistake. 2. Log at run time when a declared config value is shadowed by an empty port value. Either one would have turned a multi-hour investigation into a glance at the log. ## Related While tracing this we hit a second, independent way to lose a system prompt. The node type `flowdrop_workflow_react_agent_with_tools` declares a `system_prompt` parameter: ```yaml system_prompt: configurable: true connectable: true exposed_by_default: false required: false ``` Setting it on the sub-workflow node has no effect, because nothing inside `react_agent_with_tools` consumes it — the Reason node's port is named `systemPrompt`, and no edge or input node bridges the two. A declared, editable parameter that is wired to nothing is the same class of silent failure and may be worth folding into this issue or splitting out. ## Environment * FlowDrop 2.4.2 * Drupal 11.4.5, PHP 8.3 * Orchestrator: `flowdrop_runtime:synchronous`