The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
LangFuseSearchSpanSubscriber assigns the search query to the trace input every time a query runs: $trace->update(input: $spanInput). A single conversational turn can search several times, so the trace ends up labelled with whichever query happened to run last rather than with what the user asked.
Seen on a real trace: the user asked "tell me about dropsolid AI tiers", the agent ran five searches, and the last one was an off-topic "Langfuse integration" query it had invented. The trace input read Langfuse integration. The user's question had been recorded correctly at the start and was then overwritten four times.
This is about the trace input being replaced, not about its shape. The separate question of generations recording a flattened string rather than the message array is #3560603.
Proposed resolution
Offer the query to ensureTrace() as the initial input instead of assigning it afterwards. ensureTrace() already applies an initial input only when it creates the trace, so a search that happens during a chat leaves the user's question in place, while a search that opens its own trace still labels it with the query. That keeps the useful behaviour and drops the overwriting.
Issue fork langfuse-3618160
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
nikro commentedComment #4
nikro commentedPushed a fix. The query is now offered to
ensureTrace()as the initial input rather than assigned to the trace afterwards.ensureTrace()only applies an initial input when it creates the trace, so a search during a chat leaves the user's question in place, while a search that opens its own trace still gets labelled with the query.Verified on a local instance: the same question that previously produced a trace labelled 'Langfuse integration' now shows the actual question, with the retrieval spans still carrying their own query strings individually.
Comment #6
abhisekmazumdarReviewed the approach in MR !9. It's correct:
ensureTrace()only applies its initial input when it creates the trace, so this stops mid-chat searches from overwriting the trace input while a search that opens its own trace still gets labelled with the query.The pipeline was failing on phpcs (two over-length comment lines). Fixed and pushed.
One gap before RTBC:
LangFuseTraceInputTestcallsensureTrace()directly rather than going throughLangFuseSearchSpanSubscriber::onSearchQueryPreExecute(). It doesn't exercise the code path this MR actually changes, and would still pass if the fix were reverted. Suggest the test dispatch the search query event (or call the subscriber directly) instead.So not quite RTBC yet.