OpenTelemetry Attribute Length Limits Not Applied to AI SDK Spans

[lukasugar]

Description

Is there an example how ai-sdk and trigger.dev can be used together, with proper logging of long prompts?

When using Vercel AI SDK's experimental_telemetry feature in Trigger.dev v4 tasks, OpenTelemetry span attributes are being truncated despite setting the recommended environment variables (TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT, etc.) to very high values.

The attributes containing LLM messages, responses, and tool call data are cut off, making it difficult to debug AI-powered workflows.

Environment

• Trigger.dev Version: @trigger.dev/sdk@4.1.0
• AI SDK Version: ai@6.0.0-beta.99
• Runtime: Node.js
• Deployment: Trigger.dev Cloud

Environment Variables Set

Set in Trigger.dev project environment variables (synced from Vercel):

OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576
TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576
TRIGGER_OTEL_LOG_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576

Confirmed these are present in the task runtime via:

console.log("OTEL limits:", {
  standard: process.env.OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT,
  trigger_span: process.env.TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT,
  trigger_log: process.env.TRIGGER_OTEL_LOG_ATTRIBUTE_VALUE_LENGTH_LIMIT,
});
// Output: All show "1048576"

Task Code Example

import { task } from "@trigger.dev/sdk";
import { generateText } from "ai";
import { anthropic } from "@ai-sdk/anthropic";

export const analyzeChart = task({
  id: "analyze-chart",
  run: async (payload) => {
    const result = await generateText({
      model: anthropic("claude-sonnet-4-5"),
      prompt: "Analyze this large dataset...", // Long prompt with lots of context
      experimental_telemetry: {
        isEnabled: true,
        functionId: "analyze-chart",
        recordInputs: true,
        recordOutputs: true,
      },
    });
    
    return result.text;
  },
});

Expected Behavior

With TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576 (1MB), span attributes in the Trigger.dev trace view should contain:

• Full input prompts (up to 1MB)
• Full output text (up to 1MB)
• Complete tool call arguments and results (up to 1MB)

According to Trigger.dev's changelog, these limits were increased from 1,024 bytes to 131,072 bytes (128KB) and made fully configurable.

Actual Behavior

Span attributes are being truncated at what appears to be a much lower limit, 1024B. This makes debugging LLM conversations extremely difficult.

In Trigger.dev Trace View

• ✅ ai.generateText span appears correctly
• ✅ ai.toolCall spans appear correctly
• ✅ Span hierarchy is correct
• ❌ Attribute values are truncated (messages cut off mid-sentence)
• ❌ No indication that the 1MB limit is being respected

What We've Tried

1. Set Standard + Trigger.dev Environment Variables

OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576
TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576
TRIGGER_OTEL_LOG_ATTRIBUTE_VALUE_LENGTH_LIMIT=1048576

Result: Still truncated at ~1KB

2. Increased to 10MB

TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT=10485760

Result: No change, still truncated at same point

3. Set to Unlimited (0)

TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT=0

Result: No change, still truncated

4. Verified Environment Variables Are Present

Added logging to confirm env vars are loaded:

console.log("Limits:", process.env.TRIGGER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT);
// Output: "1048576" ✅

5. Redeployed Multiple Times

• Deleted and recreated environment variables
• Redeployed task code
• Waited for changes to propagate
  Result: No change

6. Specified all the environment variables from https://trigger.dev/changelog/increased-otel-attribute-limits

But still no changes.

Questions

Ideally if someone has a working example, that would be best. If not, these questions could help us with debugging

1. Are the TRIGGER_OTEL_* environment variables actually being applied to the TracerProvider?

   • We can see they're set in process.env, but are they being read by the OpenTelemetry SDK initialization?
   • Is there a specific timing requirement (must be set before SDK initialization)?

2. Does Trigger.dev's TracerProvider initialization happen before or after environment variables are loaded?

   • Could there be a race condition where the provider is initialized with defaults before our env vars are available?

3. Is there a different configuration required for AI SDK spans specifically?

   • Do spans created by external libraries (like AI SDK) inherit the same limits?
   • Is there additional configuration needed for third-party instrumentation?

4. Can we verify the actual limits being applied?

   • Is there a way to inspect the TracerProvider configuration at runtime?
   • Can we log the actual spanLimits being used?

5. Is the truncation happening at span creation or span export?

   • Are attributes truncated when the AI SDK creates spans?
   • Or during batch processing/export to Trigger.dev backend?

[ericallam]

@lukasugar Thank you for filing this issue and sorry about this! There are basically two places where limits are applied, the client (e.g. the task side) and the server (where logs are ingested and saved into the database).

The limits you mentioned above are all client limits. The server limit is set by us on our cloud or by self-hosters who deploy the entire platform via an env var called SERVER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT.

Currently, the SERVER_OTEL_SPAN_ATTRIBUTE_VALUE_LENGTH_LIMIT setting on the cloud is just 1024. This was in place as a protective measure when we stored logs in postgresql.

You may be asking, why would we increase the client limits AND keep the server limit of 1024 in place? Good question! That would basically allow you to use our 3rd party otel exporter support to ship AI logs with large JSON attribute values to 3rd parties like Langfuse without truncation.

But now that we've migrated our cloud to storing otel logs/spans in clickhouse, we're going to be increasing the server limit to 128KB (that's per attribute value) shortly. I will update this issue when that has been put live.

[lukasugar]

@ericallam thanks for describing the issue so well and thanks for committing to fix it. Looking forward to the change 👍

[lukasugar]

Any ETA on when the change will be live?