ActionPluginDeriver crashes AI features when an action plugin lacks an instance class (#3585335) · Issues · project / ai

ActionPluginDeriver crashes AI features when an action plugin lacks an instance class

>>> [!note] Migrated issue   Reported by: [mtift](https://www.drupal.org/user/751908) Related to !1520 >>> [Tracker] Update Summary: New bug report — defensive fix proposed Short Description: ActionPluginDeriver crashes the chat explorer when any ECA action plugin lacks a class Check-in Date: 04/23/2026 Metadata is used by the <a href="https://www.drupalstarforge.ai/" title="AI Tracker">AI Tracker.</a> Docs and additional fields <a href="https://www.drupalstarforge.ai/ai-dashboard/docs" title="AI Issue Tracker Documentation">here</a>. [/Tracker] <h3 id="summary-problem-motivation">Problem/Motivation</h3> <code>ActionPluginDeriver::getDerivativeDefinitions()</code> iterates every ECA action plugin definition and calls <code>createInstance()</code> on each one to discover available function-call tools for AI providers. If any single action plugin definition lacks an instance class, the call throws <code>PluginException</code>, which propagates up and breaks the entire AI chat explorer page (and any other AI feature that enumerates function calls). One bad action plugin anywhere in the site — including ones contributed by old or deprecated contrib modules — takes out all AI chat tooling. The trigger in our case was <code>file_entity</code> 8.x-1.14, which declares <code>pathauto_file_update_action</code> via the legacy <code>hook_action_info_alter()</code> without an instance class. That's a real bug in <code>file_entity</code> (we'll file separately), but <code>drupal/ai</code> shouldn't crash because of it — it should skip the broken definition and continue. Stack trace: <div class="codeblock"> <pre><?php Drupal\Component\Plugin\Exception\PluginException: The plugin (pathauto_file_update_action) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 79 of core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php). Drupal\Core\Plugin\Factory\ContainerFactory->createInstance() (Line: 83) Drupal\Component\Plugin\PluginManagerBase->createInstance() (Line: 178) Drupal\eca\PluginManager\Action->createInstance() (Line: 67) Drupal\ai\Plugin\AiFunctionCall\Derivative\ActionPluginDeriver->getDerivativeDefinitions() (Line: 101) Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives() (Line: 87) Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 337) Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 33) Drupal\ai\Service\FunctionCalling\FunctionCallPluginManager->getDefinitions() (Line: 202) Drupal\ai_api_explorer\Plugin\AiApiExplorer\ChatGenerator->buildForm() (Line: 60) ?></pre></div> <h4 id="summary-steps-reproduce">Steps to reproduce (required for bugs, but not feature requests)</h4> Environment: <ul> <li>Drupal core 10.x</li> <li><code>drupal/ai</code> 1.3.3</li> <li><code>ai_api_explorer</code> enabled</li> <li>ECA 2.1.x enabled</li> <li>Any module that registers an ECA action plugin definition without a <code>class</code> key (e.g., <code>file_entity</code> 8.x-1.14 with <code>pathauto</code> enabled)</li> </ul> Steps: <ol> <li>Navigate to <code>/admin/config/ai/explorers/chat_generator</code>.</li> <li>Observe a WSOD with the <code>PluginException</code> above.</li> </ol> <h3 id="summary-proposed-resolution">Proposed resolution</h3> Make <code>ActionPluginDeriver::getDerivativeDefinitions()</code> defensive: skip action definitions that lack an instance class so one bad third-party plugin can't take out every AI feature that enumerates function calls. Minimal fix in <code>src/Plugin/AiFunctionCall/Derivative/ActionPluginDeriver.php</code>: <div class="codeblock"> <pre><?php foreach ($this->actionManager->getDefinitions() as $id => $action_definition) {   // Skip plugin definitions that lack an instance class. Some legacy   // contrib modules register actions via hook_action_info_alter() without   // providing a class; those cannot be instantiated.   if (empty($action_definition['class'])) {     continue;   }   if (in_array($action_definition['type'], $supported_action_types, TRUE) || $this->entityTypeManager->getDefinition($action_definition['type'], FALSE)) {     // ... existing logic, including the createInstance() call ...   } } ?></pre></div> A <code>try/catch</code> around <code>createInstance()</code> would be a defense-in-depth alternative if maintainers prefer to also tolerate other instantiation failures. The same defensive pattern likely belongs in any other deriver in the module that enumerates third-party plugins it doesn't own. <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Decide on guard style: pre-check on <code>['class']</code>, <code>try/catch</code>, or both</li> <li>Audit other derivers in <code>src/Plugin/AiFunctionCall/Derivative/</code> for the same fragility</li> <li>Patch + test against a site with a deliberately broken action plugin</li> <li>Reviews</li> </ul> <h3>Related issues</h3> <ul> <li><a href="https://www.drupal.org/project/ai/issues/3585328" title="Status: Needs review">#3585328: Undefined array key "#type" warnings break AJAX in AbstractModelFormBase::updateModelForm()</a> — separate <code>drupal/ai</code> bug we filed in the same session, surfaced while configuring a Vertex chat model</li> </ul> <h3>Optional: Other details as applicable (e.g., User interface changes, API changes, Data model changes)</h3> No UI, API, or data model changes. The fix makes the deriver resilient to malformed third-party plugin definitions. <h3 id="summary-ai-usage">AI usage (if applicable)</h3> [x] AI Assisted Issue This issue was generated with AI assistance, but was reviewed and refined by the creator. [ ] AI Assisted Code [ ] AI Generated Code [ ] Vibe Coded

issue