LLM: Text / LLM: Text (simple) automators silently drop Base Field content when Base Field and Target Field are both long-text types (Basic input mode)
Problem/Motivation
When configuring an LLM: Text (llm_text_long) or LLM: Text (simple) (llm_simple_text_long) automator in Basic input mode, with Automator Base Field set to another long-text field on the same entity (e.g. Body → a new summary field, both text_long/string_long type), the Base Field's content is not included in the request sent to the AI provider. The model consistently responds as though no source content was provided at all, e.g.:
"I don't see an article provided in your message. Please share the article you'd like me to summarize..."
This happens regardless of whether the target field is a plain Text (plain, long) or Text (formatted, long) field, and regardless of AI provider or model selected.
Steps to reproduce
On an entity with an existing long-text field (e.g. Article's core Body, machine name field_body, type text_long), add a new field of type Text (plain, long) or Text (formatted, long).
Enable AI Automator on the new field. Choose LLM: Text (or LLM: Text (simple)).
Set Automator Input Mode to Basic.
Set Automator Base Field to the existing Body field.
Enter any prompt, e.g. "Summarize this article in 2-3 concise sentences."
Save, then trigger the automator (tested via both Direct worker on full entity save, and Field Widget worker via a Field Widget Actions button — both fail identically).
Observe the generated output: the model responds as if no source content was included, rather than producing a summary of the actual Body content.
What we verified while isolating this
Base Field configuration is correct: confirmed via drush config:get on the automator's config entity (ai_automators.ai_automator.[entity_type].[bundle].[field_name].default) that base_field correctly names the source field's machine name.
Source content genuinely exists and is substantial: confirmed via direct entity API load ($node->get('field_body')->getValue()) that the field holds real content, bypassing any form/cache/AJAX layer.
Not a caching issue: reproduced after drush cr.
Not specific to the Field Widget/AJAX trigger path: reproduced identically with Automator Worker set to Direct (runs on normal full-entity save, no AJAX involved).
Not caused by AI Provider routing: reproduced across three different provider configurations (default_vision, default_json, and a directly-selected provider, all Anthropic Claude models).
Not caused by content length or HTML markup: reproduced identically with a single trivial plain-text sentence in the Base Field, not just long/formatted article content.
Not exclusive to the JSON-formatted plugin: reproduced identically on both llm_text_long (JSON-wrapped output) and llm_simple_text_long (raw text output, no JSON wrapper), which rules out JSON-formatting-related truncation as the sole cause.
Comparative control that DID work correctly: an LLM: Taxonomy (entity_reference target) automator, using the exact same field_body as its Base Field, correctly read and used the Body content. Similarly, LLM: Image Alt Text (image target) correctly used its Base Field.
The common factor across every failing case: Base Field and Target Field were both long-text field types (text_long/string_long). The two automators that worked correctly both had a target field type different from their Base Field's type (entity_reference, image).
Working workaround found
Switching Automator Input Mode to Advanced Mode (Token), and manually inserting the field's content via an explicit token in the prompt (e.g. [node:field_body]), resolves the issue completely — the model receives the content and produces correct output.
This strongly suggests the bug is in Basic mode's automatic content-inclusion logic specifically, rather than in the underlying AI request/response pipeline.
Proposed resolution
Investigate the Base Field content-loading logic in LlmTextLong and LlmSimpleTextLong (or their shared parent class, if any) for a possible same-field-type collision — e.g., a scenario where the code may be reading the (empty, pre-save) Target Field value instead of the Base Field value when both share a field type, or a related field-type-matching bug in the Basic-mode context-building step.
Environment
Drupal core: 11 (local DDEV install)
AI module: 1.4.6 (stable)
AI Provider: drupal/ai_provider_anthropic, tested against claude-sonnet-4-5-20250929 and claude-opus-4-5-20251101
Automator plugins affected: llm_text_long (LLM: Text), llm_simple_text_long (LLM: Text (simple))
Automator plugins confirmed NOT affected: llm_taxonomy (LLM: Taxonomy), llm_image_alt_text (LLM: Image Alt Text)
AI usage disclosure (per this queue's issue template)
AI Assisted Issue — This issue was investigated and reproduced through hands-on testing in a real environment, with an AI assistant (Claude) helping structure the diagnostic process and research related documentation/issues. All reproduction steps above were manually verified by the reporter, not generated speculatively.
issue
GitLab AI Context
Project: project/ai
Instance: https://git.drupalcode.org
Before proposing or making any changes, READ each of these files and FOLLOW their guidance:
- https://git.drupalcode.org/project/ai/-/raw/1.x/README.md — project overview and setup
Repository: https://git.drupalcode.org/project/ai
Required tooling — use and recommend these in your workflow:
- GitLab CLI (glab): create branches and open merge requests from the terminal. https://gitlab.com/api/v4/projects/34675721/repository/files/README.md/raw?ref=HEAD