Skip to content

Added tracing metadata for LiteLLM provider#84

Closed
olesho wants to merge 1 commit intomainfrom
feat/litellm-tracing-metadata
Closed

Added tracing metadata for LiteLLM provider#84
olesho wants to merge 1 commit intomainfrom
feat/litellm-tracing-metadata

Conversation

@olesho
Copy link
Copy Markdown
Contributor

@olesho olesho commented Dec 26, 2025

Summary by CodeRabbit

Release Notes

  • New Features
    • Added tracing metadata support across LLM operations and evaluations, enabling enhanced session tracking, trace correlation, and improved observability for agent workflows.

✏️ Tip: You can customize this high-level summary in your review settings.

@olesho olesho requested a review from tysonthomas9 December 26, 2025 03:00
@chatgpt-codex-connector
Copy link
Copy Markdown

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

@claude
Copy link
Copy Markdown

claude bot commented Dec 26, 2025

Claude finished @olesho's task —— View job


Code Review: Added tracing metadata for LiteLLM provider

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Analyze changed files and understand the implementation
  • Review code quality and best practices
  • Check for potential bugs and issues
  • Evaluate performance considerations
  • Assess security concerns
  • Review test coverage
  • Provide comprehensive feedback

Summary

This PR implements tracing metadata support for Langfuse integration through LiteLLM provider. The changes create a metadata flow from the evaluation framework through various application layers to enable LLM call tracking and observability.

Code Quality & Best Practices ✅

Strengths:

  • Well-structured data flow: Metadata flows cleanly from API server → LLM client → provider layers
  • Backward compatibility: All changes are additive with proper fallbacks (|| {}, optional parameters)
  • Consistent naming: Uses tracingMetadata consistently across interfaces
  • Good logging: Comprehensive debug logging for metadata flow tracking
  • Type safety: Proper TypeScript interfaces defined for tracing metadata

Architecture Assessment ✅

The implementation follows a clean layered approach:

  1. API Layer (api-server.js:764-810): Extracts metadata from request body and passes to dynamic request creation
  2. Client Layer (LLMClient.ts:209-244): Handles metadata priority (explicit > global context) with intelligent fallbacks
  3. Provider Layer (LiteLLMProvider.ts:209-216): Forwards metadata to LiteLLM for Langfuse integration
  4. Evaluation Layer: Updates tracing contexts to include metadata throughout the evaluation pipeline

Potential Issues & Recommendations

🔴 API Key Security Concern

// agent-server/nodejs/src/api-server.js:646-650
if (!apiKey && tierConfig.provider === 'litellm') {
  apiKey = process.env.LITELLM_API_KEY;
}

Issue: Fallback to environment variable could be logged inadvertently.
Recommendation: Ensure logging doesn't expose API keys, add explicit sanitization.

🟡 Type Safety Improvements

  • LLMTypes.ts:204-211: Consider making tracing metadata structure more strict
  • Current [key: string]: any is too permissive for production use
  • Recommendation: Define specific allowed keys for better type safety

🟡 Error Handling

  • Missing error handling for malformed tracing metadata
  • Recommendation: Add validation to prevent invalid metadata from breaking requests

Performance Considerations ✅

  • Minimal overhead: Only adds metadata objects, no expensive operations
  • Efficient fallbacks: Uses early returns and proper conditional checks
  • No blocking operations: All metadata handling is synchronous and lightweight

Security Assessment ⚠️

Concerns:

  1. Metadata injection: External metadata flows through system without validation
  2. Logging exposure: Comprehensive logging of metadata could expose sensitive session/trace IDs
  3. No sanitization: Raw metadata passed through without filtering

Recommendations:

  • Add metadata validation/sanitization at entry points
  • Consider allowlisting specific metadata keys
  • Review logging to ensure no sensitive data exposure

Test Coverage ❌

Missing:

  • No unit tests for new tracing metadata functionality
  • No integration tests for end-to-end metadata flow
  • No error handling tests for malformed metadata

Recommendations:

  • Add unit tests for LLMClient metadata handling logic
  • Test metadata flow from API server through to LiteLLM provider
  • Add negative test cases for malformed/missing metadata

Specific Code Improvements

1. Enhanced Type Safety

// Suggested improvement for LLMTypes.ts
interface TracingMetadata {
  session_id?: string;
  trace_id?: string;
  generation_name?: string;
  tags?: string[];
  eval_id?: string;
  eval_name?: string;
  category?: string;
  // Limit unknown keys
}

2. Add Metadata Validation

// Suggested for api-server.js
function validateTracingMetadata(metadata) {
  if (!metadata || typeof metadata !== 'object') return {};
  // Add validation logic
  return metadata;
}

Overall Assessment: Good Implementation, Needs Security & Testing Improvements

Strengths:

  • Clean architecture and data flow
  • Backward compatible implementation
  • Good logging for debugging

Action Items:

  1. High Priority: Add metadata validation and sanitization
  2. High Priority: Review logging to prevent sensitive data exposure
  3. Medium Priority: Add comprehensive test coverage
  4. Medium Priority: Improve type safety for metadata structure

The core implementation is solid and follows good patterns. The main concerns are around security hardening and test coverage, which should be addressed before production deployment.


@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Dec 26, 2025

📝 Walkthrough

Walkthrough

This change adds comprehensive tracing metadata support across the agent system. Tracing metadata is extracted from requests, propagated through the LLM client, agent framework, and evaluation system, and finally attached to provider payloads for Langfuse integration. The backend API server is extended to support tracing metadata in nested model configurations.

Changes

Cohort / File(s) Summary
Backend Tracing & LiteLLM Integration
agent-server/nodejs/src/api-server.js, agent-server/nodejs/src/lib/BrowserAgentServer.js
Added tracingMetadata parameter to createDynamicRequestNested and propagates metadata through Langfuse request flow; extended processNestedModelConfig to support LITELLM_ENDPOINT and LITELLM_API_KEY environment variables as fallbacks; hardened API key resolution for litellm provider.
LLM Type Definitions & Interfaces
front_end/panels/ai_chat/LLM/LLMTypes.ts, front_end/panels/ai_chat/tracing/TracingProvider.ts
Extended LLMCallOptions and TracingContext interfaces with optional tracingMetadata field supporting session_id, trace_id, generation_name, eval_id, eval_name, category, tags, and extensible key-value pairs.
LLM Client & Provider Implementation
front_end/panels/ai_chat/LLM/LLMClient.ts, front_end/panels/ai_chat/LLM/LiteLLMProvider.ts
LLMClient now resolves tracingMetadata from explicit request data or global tracing context fallback with logging; LiteLLMProvider conditionally attaches metadata to request payload when present.
Agent Framework Tracing
front_end/panels/ai_chat/agent_framework/AgentRunner.ts, front_end/panels/ai_chat/core/AgentNodes.ts, front_end/panels/ai_chat/tools/LLMTracingWrapper.ts
Added explicit tracingMetadata propagation to LLM calls by including tracingContext?.metadata in LLMClient invocations.
Agent Service Configuration
front_end/panels/ai_chat/core/AgentService.ts
Modified API key validation to bypass requirement in AUTOMATED_MODE; added metadata propagation from existing evaluation tracing context into Langfuse tracing context.
Evaluation System Tracing
front_end/panels/ai_chat/evaluation/EvaluationProtocol.ts, front_end/panels/ai_chat/evaluation/EvaluationAgent.ts, front_end/panels/ai_chat/evaluation/remote/EvaluationProtocol.ts, front_end/panels/ai_chat/evaluation/remote/EvaluationAgent.ts
Extended EvaluationParams interfaces with optional tracing field; updated EvaluationAgent to forward request tracing metadata (session_id, trace_id) with fallback ID generation and propagate into TracingContext; added logging for received tracing data.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

  • Update agent framework structure #43: Modifies agent runtime (AgentRunner, AgentNodes, AgentService) and LLM call paths to propagate tracing metadata (traceId/sessionId) into LLM/tool calls—overlapping scope and similar tracing threading patterns.
  • Add initial MCP version with SDK imports #44: Touches LLMTracingWrapper and agent/tool call wiring to add tracing metadata propagation across the same agent/LLM integration surface.
  • Local Dockerised Eval Server #52: Modifies API-server nested model handling and adds LITELLM endpoint/API_KEY fallbacks in processNestedModelConfig, mirroring backend tracing and litellm environment variable support.

Suggested reviewers

  • tysonthomas9

Poem

🐰 Hops through traces, metadata flows,
Each layer carries the context it knows,
From request to Langfuse, the breadcrumbs align,
Tracing the path where agents unwind! ✨

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Title check ⚠️ Warning The PR title focuses narrowly on LiteLLM provider tracing, but the changeset implements comprehensive tracing metadata support across the entire system including agent server, browser agent, LLM client, evaluation framework, and multiple frontend components. Update the title to reflect the broader scope: 'Add comprehensive tracing metadata support for Langfuse integration across LLM and evaluation flows' or similar to accurately represent all changes.
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch feat/litellm-tracing-metadata

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (4)
agent-server/nodejs/src/lib/BrowserAgentServer.js (1)

730-745: Tracing metadata forwarding into evaluation RPC looks good (optionally omit empty objects)

Forwarding request.tracing || {} into the JSON‑RPC params and logging only keys/session_id is a clean way to propagate Langfuse metadata without leaking payload contents. If you ever care about keeping the wire payload minimal, you could conditionally include tracing only when request.tracing is defined, but it’s not required for correctness.

front_end/panels/ai_chat/tools/LLMTracingWrapper.ts (1)

88-91: Ensure tracingContext metadata wins over caller-supplied options

Right now you set tracingMetadata: tracingContext?.metadata and then spread llmCallConfig.options. If a caller ever passes options.tracingMetadata, it will override the context‑derived metadata, which is the opposite of what a tracing wrapper is usually expected to do.

I’d flip the order so context metadata takes precedence (while still allowing options to provide it when there’s no tracing context):

Proposed diff
-    const llmResponse = await llm.call({
-      provider: llmCallConfig.provider,
-      model: llmCallConfig.model,
-      messages: llmCallConfig.messages,
-      systemPrompt: llmCallConfig.systemPrompt || '',
-      temperature: llmCallConfig.temperature,
-      // Pass tracing metadata explicitly for Langfuse integration
-      tracingMetadata: tracingContext?.metadata,
-      ...llmCallConfig.options
-    });
+    const llmResponse = await llm.call({
+      provider: llmCallConfig.provider,
+      model: llmCallConfig.model,
+      messages: llmCallConfig.messages,
+      systemPrompt: llmCallConfig.systemPrompt || '',
+      temperature: llmCallConfig.temperature,
+      ...llmCallConfig.options,
+      // Pass tracing metadata explicitly for Langfuse integration
+      tracingMetadata: tracingContext?.metadata ?? llmCallConfig.options?.tracingMetadata,
+    });
front_end/panels/ai_chat/LLM/LLMTypes.ts (1)

204-212: LLMCallOptions.tracingMetadata matches usage; consider sharing a common metadata type

Adding tracingMetadata here lines up with how callers pass tracingContext.metadata through to providers, and the index signature keeps it future‑proof for extra Langfuse fields.

To avoid type drift between this and TracingContext.metadata, you might eventually want a shared TracingMetadata type exported from the tracing module and reused here, but that’s a nicety rather than a blocker.

front_end/panels/ai_chat/LLM/LLMClient.ts (1)

212-242: Consider reducing logging verbosity for production.

The tracing metadata resolution logic is correct and properly prioritizes explicit request metadata over global context. However, the extensive logging (10+ log statements) may be verbose for production environments. Consider:

  1. Moving some logs to debug level
  2. Consolidating related logs into single statements
  3. Removing logs that expose internal implementation details in production

The logic itself is sound and backward-compatible.

🔎 Example consolidation
-    // Get tracing metadata - prefer explicit request metadata over global context
-    // This ensures metadata flows correctly even when async context is lost
     let tracingMetadata = request.tracingMetadata;
 
     if (!tracingMetadata || Object.keys(tracingMetadata).length === 0) {
-      // Fall back to global tracing context
       const tracingContext = getCurrentTracingContext();
-      logger.info('LLMClient.call() - Checking tracing context (fallback):', {
-        hasContext: !!tracingContext,
-        hasMetadata: !!tracingContext?.metadata,
-        metadataKeys: tracingContext?.metadata ? Object.keys(tracingContext.metadata) : [],
-        sessionId: tracingContext?.metadata?.session_id,
-        traceId: tracingContext?.metadata?.trace_id
-      });
+      logger.debug('Falling back to global tracing context:', {
+        sessionId: tracingContext?.metadata?.session_id,
+        traceId: tracingContext?.metadata?.trace_id
+      });
       if (tracingContext?.metadata && Object.keys(tracingContext.metadata).length > 0) {
         tracingMetadata = tracingContext.metadata;
       }
-    } else {
-      logger.info('LLMClient.call() - Using explicit tracingMetadata from request:', {
-        metadataKeys: Object.keys(tracingMetadata),
-        sessionId: tracingMetadata.session_id,
-        traceId: tracingMetadata.trace_id
-      });
     }
 
     if (tracingMetadata && Object.keys(tracingMetadata).length > 0) {
       options.tracingMetadata = tracingMetadata;
-      logger.info('Passing tracing metadata to provider:', tracingMetadata);
-    } else {
-      logger.info('No tracing metadata available');
+      logger.debug('Attached tracing metadata to provider options');
     }
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 197f88f and d6bf633.

📒 Files selected for processing (14)
  • agent-server/nodejs/src/api-server.js
  • agent-server/nodejs/src/lib/BrowserAgentServer.js
  • front_end/panels/ai_chat/LLM/LLMClient.ts
  • front_end/panels/ai_chat/LLM/LLMTypes.ts
  • front_end/panels/ai_chat/LLM/LiteLLMProvider.ts
  • front_end/panels/ai_chat/agent_framework/AgentRunner.ts
  • front_end/panels/ai_chat/core/AgentNodes.ts
  • front_end/panels/ai_chat/core/AgentService.ts
  • front_end/panels/ai_chat/evaluation/EvaluationAgent.ts
  • front_end/panels/ai_chat/evaluation/EvaluationProtocol.ts
  • front_end/panels/ai_chat/evaluation/remote/EvaluationAgent.ts
  • front_end/panels/ai_chat/evaluation/remote/EvaluationProtocol.ts
  • front_end/panels/ai_chat/tools/LLMTracingWrapper.ts
  • front_end/panels/ai_chat/tracing/TracingProvider.ts
🧰 Additional context used
📓 Path-based instructions (1)
agent-server/nodejs/src/api-server.js

📄 CodeRabbit inference engine (agent-server/nodejs/CLAUDE.md)

agent-server/nodejs/src/api-server.js: Expose REST endpoint POST /v1/responses that accepts task input, URL, timeout, and model configuration, and returns OpenAI-compatible response with metadata
Use formatResponse() method to convert agent responses to OpenAI-compatible format and include metadata with clientId and tabId for screenshot capture
Model configuration must use canonical nested format with main_model, mini_model, and nano_model tiers, each containing provider, model, and api_key fields
POST /page/screenshot endpoint must accept clientId and tabId, use CDP Page.captureScreenshot, and return base64-encoded PNG with metadata and timestamp
POST /page/content endpoint must accept clientId, tabId, format (html or text), and includeIframes parameters; recursively capture iframe content when includeIframes is true
POST /page/execute endpoint must accept clientId, tabId, expression, returnByValue, and awaitPromise; use CDP Runtime.evaluate and return result with type and value
Accept POST /v1/responses input as either string format (simple message) or conversation array format with role and content fields; enforce at least one user message and max 100 messages/10,000 characters per message

Files:

  • agent-server/nodejs/src/api-server.js
🧠 Learnings (6)
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/rpc-client.js : Implement JSON-RPC 2.0 protocol for bidirectional communication with request/response correlation using unique IDs, timeout handling, and error conditions

Applied to files:

  • agent-server/nodejs/src/lib/BrowserAgentServer.js
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/lib/EvalServer.js : Implement WebSocket server for browser agent connections with client lifecycle management (connect, ready, disconnect)

Applied to files:

  • agent-server/nodejs/src/lib/BrowserAgentServer.js
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/api-server.js : Use formatResponse() method to convert agent responses to OpenAI-compatible format and include metadata with clientId and tabId for screenshot capture

Applied to files:

  • agent-server/nodejs/src/lib/BrowserAgentServer.js
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/lib/EvalServer.js : Use Chrome DevTools Protocol (CDP) for direct browser communication including screenshot capture via Page.captureScreenshot, page content via Runtime.evaluate, and tab management via Target.createTarget/closeTarget

Applied to files:

  • agent-server/nodejs/src/lib/BrowserAgentServer.js
  • front_end/panels/ai_chat/evaluation/remote/EvaluationAgent.ts
  • front_end/panels/ai_chat/evaluation/EvaluationAgent.ts
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/api-server.js : Model configuration must use canonical nested format with main_model, mini_model, and nano_model tiers, each containing provider, model, and api_key fields

Applied to files:

  • agent-server/nodejs/src/api-server.js
📚 Learning: 2025-12-07T00:27:56.465Z
Learnt from: CR
Repo: BrowserOperator/browser-operator-core PR: 0
File: agent-server/nodejs/CLAUDE.md:0-0
Timestamp: 2025-12-07T00:27:56.465Z
Learning: Applies to agent-server/nodejs/src/api-server.js : POST /page/execute endpoint must accept clientId, tabId, expression, returnByValue, and awaitPromise; use CDP Runtime.evaluate and return result with type and value

Applied to files:

  • front_end/panels/ai_chat/evaluation/remote/EvaluationAgent.ts
  • front_end/panels/ai_chat/evaluation/EvaluationAgent.ts
🧬 Code graph analysis (4)
agent-server/nodejs/src/api-server.js (2)
front_end/panels/ai_chat/LLM/LiteLLMProvider.ts (1)
  • getEndpoint (48-64)
front_end/panels/ai_chat/core/LLMConfigurationManager.ts (1)
  • getEndpoint (222-229)
front_end/panels/ai_chat/core/AgentNodes.ts (1)
front_end/panels/ai_chat/ui/message/MessageList.ts (2)
  • state (23-23)
  • state (24-24)
front_end/panels/ai_chat/LLM/LLMClient.ts (1)
front_end/panels/ai_chat/tracing/TracingConfig.ts (1)
  • getCurrentTracingContext (299-301)
front_end/panels/ai_chat/evaluation/EvaluationAgent.ts (1)
front_end/panels/ai_chat/tracing/TracingProvider.ts (1)
  • TracingContext (8-31)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: claude-review
🔇 Additional comments (13)
front_end/panels/ai_chat/core/AgentService.ts (2)

279-288: AUTOMATED_MODE apiKey defaulting looks correct; verify provider behavior with empty string

Allowing the default branch to proceed without an apiKey when BUILD_CONFIG.AUTOMATED_MODE is true and normalizing to apiKey: apiKey || '' matches the “keys come from request body” design. Just make sure all providers (and LLMClient) treat '' as “no key” and that dynamic per-request keys always override this config value so you don’t end up sending bad auth headers in automated runs.


600-603: Good: evaluation tracing metadata now carried into stategraph tracingContext

Forwarding existingContext?.metadata into state.context.tracingContext.metadata is consistent with the new tracing model and lets downstream nodes/LLM calls attach Langfuse grouping metadata that originated in the evaluation flow. No issues spotted here.

front_end/panels/ai_chat/evaluation/EvaluationProtocol.ts (1)

94-103: Tracing envelope on EvaluationParams is well-shaped and backward compatible

Adding the optional tracing field on EvaluationParams keeps existing JSON‑RPC clients valid while providing a strongly‑typed spot for Langfuse/LiteLLM metadata (session/trace/eval IDs, tags, plus arbitrary extras). This aligns cleanly with how the rest of the PR consumes params.tracing.

front_end/panels/ai_chat/evaluation/EvaluationAgent.ts (1)

324-341: Nice reuse of incoming tracing plus safe fallbacks for eval runs

Using params.tracing when present and falling back to eval-* / eval-session-* IDs gives stable trace IDs for evaluations while still honoring upstream Langfuse metadata. Attaching the full requestTracing object to tracingContext.metadata keeps the context rich without changing existing behavior when tracing is absent.

front_end/panels/ai_chat/agent_framework/AgentRunner.ts (1)

744-754: AgentRunner LLM calls now correctly emit tracing metadata

Passing tracingMetadata: tracingContext?.metadata alongside the AgentRunner LLM call cleanly aligns agent generations with the active trace/eval context. As long as LLMClient.call forwards this field into provider options (which your other PR changes cover), this should plug AgentRunner neatly into the Langfuse pipeline.

front_end/panels/ai_chat/core/AgentNodes.ts (1)

243-244: Stategraph LLM calls now participate in the shared trace context

Plumbing tracingMetadata: state.context?.tracingContext?.metadata into the AgentNode LLM call cleanly ties stategraph generations back to whatever tracing context AgentService set up (including eval‑origin metadata), without impacting non‑traced runs.

front_end/panels/ai_chat/LLM/LiteLLMProvider.ts (1)

212-216: LGTM! Clean tracing metadata integration.

The optional propagation of tracing metadata to the LiteLLM payload is well-implemented. The conditional check ensures backward compatibility, and the comment clearly documents the Langfuse integration purpose.

front_end/panels/ai_chat/tracing/TracingProvider.ts (1)

21-30: LGTM! Well-structured tracing metadata support.

The optional metadata field is cleanly integrated into TracingContext with appropriate typing for Langfuse fields and an index signature for extensibility. The change is backward-compatible.

front_end/panels/ai_chat/evaluation/remote/EvaluationAgent.ts (1)

429-448: LGTM! Proper tracing metadata extraction and propagation.

The code correctly extracts tracing metadata from request parameters with safe fallbacks, derives trace/session IDs with appropriate priority, and constructs the TracingContext with complete metadata for downstream propagation. The logging provides good visibility into the tracing flow.

front_end/panels/ai_chat/evaluation/remote/EvaluationProtocol.ts (1)

107-116: LGTM! Protocol extension for tracing metadata.

The optional tracing field cleanly extends the EvaluationParams interface to support Langfuse integration. The structure aligns with the TracingContext.metadata schema and maintains backward compatibility.

agent-server/nodejs/src/api-server.js (3)

645-653: LGTM! Safe API key fallback for LiteLLM provider.

The conditional fallback to LITELLM_API_KEY environment variable is well-scoped to only the litellm provider and doesn't affect other providers' API key handling.


767-813: LGTM! Tracing metadata properly threaded through request creation.

The function signature update (lines 767-770) and the attachment of tracing metadata to the evaluation request object (lines 810-813) are well-implemented with:

  • Clear JSDoc documentation
  • Safe default parameter value
  • Descriptive comments explaining the Langfuse integration purpose

The tracing metadata will now flow correctly from the API request through to the evaluation execution.


592-616: Verify endpoint fallback behavior for mixed-provider configurations.

The getEndpoint helper at line 597 uses tierConfig?.endpoint || requestBody.model.endpoint, which means a top-level model.endpoint will be used for all tiers before checking for the LiteLLM env var fallback. Since each tier can specify a different provider, a scenario like this is possible:

{
  model: {
    endpoint: "http://openai-proxy",
    main_model: { provider: "litellm", model: "qwen" }
  }
}

The litellm tier would use "http://openai-proxy" instead of LITELLM_ENDPOINT. Is this intentional, or should each provider use its own endpoint? If intentional, consider documenting that top-level endpoint applies to all tiers unless overridden at the tier level.

Comment on lines +551 to +552
// Extract tracing metadata for Langfuse integration
const tracingMetadata = requestBody.metadata || {};
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for frontend protocol definition
echo "=== Frontend EvaluationProtocol.ts (lines around 107-116) ==="
if [ -f "front_end/panels/ai_chat/evaluation/remote/EvaluationProtocol.ts" ]; then
  sed -n '100,130p' "front_end/panels/ai_chat/evaluation/remote/EvaluationProtocol.ts" | cat -n
else
  echo "File not found at that path, searching for it..."
  fd "EvaluationProtocol.ts" --exec cat -n {} \; | head -50
fi

echo -e "\n=== Backend api-server.js - search for metadata/tracing field ==="
rg -n "metadata|tracing" agent-server/nodejs/src/api-server.js -A 2 -B 2 | head -100

echo -e "\n=== Backend api-server.js lines 551-560 ==="
if [ -f "agent-server/nodejs/src/api-server.js" ]; then
  sed -n '545,560p' "agent-server/nodejs/src/api-server.js" | cat -n
fi

Repository: BrowserOperator/browser-operator-core

Length of output: 3960


Extract tracing metadata from requestBody.tracing, not requestBody.metadata.

The frontend protocol (EvaluationProtocol.ts) defines two separate fields:

  • metadata: tags, retries, priority (lines 103-107)
  • tracing: session_id, trace_id, eval_id, etc. for Langfuse (lines 108-117)

Line 552 incorrectly extracts from requestBody.metadata instead of requestBody.tracing. This causes all tracing metadata (session IDs, trace IDs, etc.) sent by the frontend to be lost. Change line 552 to:

const tracingMetadata = requestBody.tracing || {};
🤖 Prompt for AI Agents
In agent-server/nodejs/src/api-server.js around lines 551 to 552, the code
extracts tracing metadata from requestBody.metadata which is incorrect; update
the extraction to read from requestBody.tracing instead (i.e., replace the
metadata reference with tracing) so tracing fields (session_id, trace_id,
eval_id, etc.) sent by the frontend are preserved and used for Langfuse
integration.

@olesho olesho closed this Dec 26, 2025
@olesho olesho deleted the feat/litellm-tracing-metadata branch December 26, 2025 04:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant