`Drupal\tool_ai_connector\Plugin\AiFunctionCall\ToolPluginBase::getReadableOutput()` recomputes its output live from the underlying `tool` plugin instance every time it is called, via: ```php // tool_ai_connector/src/Plugin/AiFunctionCall/ToolPluginBase.php elseif ($this->getPluginInstance()?->getResult()?->isSuccess()) { ``` The underlying tool's result (`Drupal\tool\Tool\ToolBase::$result`) is a typed property with **no default value**, so it is *uninitialized* — not `null` — until `execute()` runs. `ToolBase::getResult()` **throws `\BadMethodCallException`** in that state rather than returning `null`: ```php // src/Tool/ToolBase.php public function getResult(): ExecutableResult { if (!isset($this->result)) { throw new \BadMethodCallException('The action result cannot be retrieved until the action ::execute() method has been called.'); } return $this->result; } ``` The null-safe operator `?->` only short-circuits on a `null` receiver — it does **not** catch a thrown exception. `ToolPluginBase::getPluginInstance()` lazily *creates* a fresh, un-executed tool instance on demand, so it is never `null` and the chain reaches `getResult()`, which throws. The unsuccessful `else` branch (`getResult()->getMessage()`) has no guard at all. The behaviour looks intermittent because it depends on whether `getReadableOutput()` is called **after** the tool executed (works) or **before** execution (throws). ## Steps to reproduce The bug is in `tool_ai_connector`'s `ToolPluginBase` and is reproducible against the sub-module directly, independent of any specific consumer: 1. Create a `ToolPluginBase` derivative (any `tool` plugin exposed via `tool_ai_connector`). 2. Call `getReadableOutput()` **before** calling `execute()` on it — e.g.: ```php /** @var \Drupal\ai\Service\FunctionCalling\FunctionCallPluginManager $manager */ $tool = $manager->createInstance('tool:some_tool'); // No execute() call yet. $tool->getReadableOutput(); ``` 3. **Observed:** `\BadMethodCallException: The action result cannot be retrieved until the action ::execute() method has been called.` **Expected:** a stable string is returned (empty, or any output previously stored via `setOutput()`), with no exception. This is also hit in practice whenever a consumer reads the readable output of a `tool_ai_connector` function call before its `execute()` has run — for example the second reproduction below, which is the common real-world trigger: - Serialize/restore a function-call object: `FunctionCallBase::setOutput($previous_output)` stores the output into `$stringOutput`, but `ToolPluginBase` **overrides** `getReadableOutput()` and ignores `$stringOutput`, recomputing from the fresh, un-executed instance → throws. ## Root cause - `ToolBase::$result` is `protected ?ExecutableResult $result;` (no initializer) → uninitialized, not `null`. - `ToolBase::getResult()` / `getResultStatus()` / `getResultMessage()` throw `\BadMethodCallException` before `execute()`. - `tool_ai_connector`'s `ToolPluginBase::getReadableOutput()` dereferences `getResult()` guarded only by `?->` (which does not catch the exception) and, in the unsuccessful branch, by nothing at all. - `ToolPluginBase` overrides `FunctionCallBase::getReadableOutput()` and never reads back the `$stringOutput` populated by `setOutput()`, so any previously-stored output is lost and the method always tries to recompute from live (possibly un-executed) plugin state. ### Drupal version 11 ### Tool module version Latest beta ### AI usage (if applicable) - [x] **AI Assisted Issue:** This issue was generated with AI assistance, but was reviewed and refined by the creator. - [ ] **AI Assisted Code:** This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. - [ ] **AI Generated Code:** This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human. - [ ] **Vibe Coded:** This code was generated by an AI and has only been functionally tested.