configureAiSdkTracing(): singleton pattern causes stale threadId/userId on long-lived servers

[young-mini-thomas]

Bug

configureAiSdkTracing() in deepeval-ts@0.1.17 causes all conversations on a long-lived server process to share the first caller's threadId and userId. Every trace in Confident AI shows the same confident.trace.thread_id regardless of which conversation it belongs to.

Root cause

In dist/integrations/ai-sdk/index.js:

function configureAiSdkTracing(options) {
    _currentOptions = options || {};     // Line 21: reassigns variable to NEW object
    if (_deepevalAiSdkTracer) {
        return _deepevalAiSdkTracer;     // Line 23: returns cached tracer
    }
    // First call only:
    new DeepEvalSpanProcessor(_currentOptions)  // Line 58: captures reference to object #1
}

The DeepEvalSpanProcessor is constructed once and stores a reference to the first options object. On subsequent calls, line 21 reassigns _currentOptions to a new object (= options || {}), so the processor's this.options still points at the original object with the first caller's threadId.

Reproduction

1. Deploy a Next.js app (production mode, not dev/turbopack) that calls configureAiSdkTracing({ threadId: chatId }) per request with different threadId values
2. Send messages on two different conversations
3. Check Confident AI — both traces have the same confident.trace.thread_id

Note: this does not reproduce in Next.js dev mode because turbopack re-evaluates modules per request, resetting the singleton.

Environment

• deepeval-ts@0.1.17
• Next.js 16 (standalone output on Azure App Service)
• AI SDK v6 (experimental_telemetry)