Problem/Motivation

This is a pretty complex one - deepchat breaks down a single interaction into multi-ajax requests.

So far Langfuse treated 1 drupal lifecycle as 1 request. And deepchat forces us to change that.
We would need to introduce multiple changes to the SDK to make it work properly, non-breaking changes (add serialization, a few setters, etc).

Keeping 1 single interaction: Question / Reply as 1 single trace will make the tracing way more understandable.

Steps to reproduce

Use deepchat - use an assistant that can delegate a task to another agent - you will see that it will break the trace into 2 logged traces.

Issue fork langfuse-3561460

Command icon 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:

Comments

nikro created an issue. See original summary.

nikro’s picture

Status: Active » Fixed

Closing this as fixed. It never got its own merge request — the work landed through #3594090's MR !4, which merged as c0c8a0d on 1.x.

The two issues turned out to be the same problem seen from opposite ends. #3594090 was that a trace lived in global state and could leak between users; this one was that a Deep Chat question and its reply came out as separate traces. Both came down to the same thing: there was no per-owner, per-turn identity for a conversation, so the code either shared one trace too widely or minted a new one per request. Once #3594090 introduced ThreadTraceStore to key a trace to its owner and its turn, this issue was a matter of using that identity across the continuation polls, and splitting it into a second MR against the same files would only have created conflicts.

The seven commits that carry this issue's number, all in c0c8a0d:

1b81e73  feat: allow a request to continue an existing trace by id
34b45a9  fix:  keep a whole turn on one trace across continuation polls
4b02714  test: cover turn boundaries, continuation and conversation isolation
9d0ef39  fix:  do not break AI operations that run outside a conversation
b9e501b  fix:  scope conversation trace mappings to their owner
ec077b8  test: assert a user cannot continue another user's turn
d4355d4  fix:  require the request stack and keep optional arguments last

What that adds up to, behaviour-wise: a question and its answer now stay on one trace no matter how many AJAX requests the continuation takes, a new question starts a new trace, and the mapping is keyed to its owner so one user cannot land on another user's trace. The mapping expires after 15 minutes, which bounds a single turn rather than a whole conversation, and anything running outside a conversation still gets its own trace instead of erroring.

Eight kernel tests in LangFuseTraceIsolationTest guard it, including testContinuationRequestsShareOneTrace() and testNewTurnStartsNewTrace() which are this issue's specific cases, plus testConversationsAreScopedToTheirOwner() for the cross-user side.

Credit is recorded on #3594090 since that is where the MR and the review happened.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.