The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agents-manage-ui	Ready	Preview, Comment	Mar 3, 2026 10:53pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
agents-api	Ignored	Preview	Mar 3, 2026 10:53pm
agents-docs	Ignored	Preview	Mar 3, 2026 10:53pm

🦋 Changeset detected

Latest commit: 18adcb0

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Improves trace observability by fixing the agent.name span attribute and adding an "Errors only" filter to the traces UI.

API (agents-api)

• Adds agentName to AgentConfig and passes it from generateTaskHandler.ts so agent.name in trace spans uses the actual agent name instead of the (missing) config.name
• Sets agent.name attribute on the chat route's message span (chat.ts)

Traces UI (agents-manage-ui)

• Adds an "Errors only" toggle button to the traces page filter bar
• Threads hasErrors through query state (use-traces-query-state.ts), the stats hook (use-traces.ts), and the SigNoz API client (signoz-stats.ts) to filter on hasError = true
• Renders message content with whitespace-pre-wrap and unescaped newlines in both timeline items and the detail panel

  ^{｜ View workflow run ｜ Using Claude Code ｜ Triggered by Pullfrog ｜ pullfrog.com ｜ 𝕏}

No documentation updates required for this PR.

The changes are:

• Error filter (hasErrors): UI enhancement for filtering conversations with errors
• Newline rendering: Visual improvement for message content display
• Agent name fix: Internal tracing attribute correction

These are UI/internal improvements that don't require user-facing documentation updates.

@claude
a.messageContent?.replaceAll('\n', '\n')

check this
i think this means we are double encoding it somewhere, or not decoding it right
and it doesnt cover text serialization generally
like even \t or \r would not work here

Claude finished @robert-inkeep's task in 4m 22s —— View job

Investigating double-encoding of message content in traces

• Gather context — read the UI files using replaceAll('\\n', '\n')
• Trace the data flow upstream — find where message content is serialized/stored
• Identify the root cause of double encoding
• Provide findings and recommendation

You're right — the .replaceAll('\\n', '\n') is a band-aid that only handles \n and misses \t, \r, \", etc. Here's the full data flow and where the issue lives:

Data flow

1. API sets span attribute — chat.ts:324, chatDataStream.ts:348, mcp.ts:213, TriggerService.ts:813 all set 'message.content' as a plain string with actual newline characters (extracted via extractTextFromParts() in message-parts.ts:79-84)
2. OTEL exports to SigNoz — the OTEL SDK serializes the attribute and sends it to the collector, which stores it in ClickHouse
3. SigNoz API returns data — the conversation route (agents-manage-ui/src/app/api/signoz/conversations/[conversationId]/route.ts) queries it back with STRING_TAG field config and reads it via getString() (line 57-60), which just returns the raw value
4. UI renders — timeline-item.tsx:86 and render-panel-content.tsx:264 apply the workaround

Root cause

The escaping happens in the ClickHouse/SigNoz storage layer. ClickHouse stores string values with C-style escape sequences — actual newlines (0x0A) become the literal two-character string \n, tabs become \t, etc. When queried back via the SigNoz API, these come back as literal escape sequences, not as the original characters. This is a known ClickHouse behavior with its string handling/output formats.

This is not a double-encoding bug in our code — our API correctly sets plain text attributes. The escaping is introduced by the storage/query layer we don't control.

Recommended fix

Instead of scattered .replaceAll('\\n', '\n') calls at render time, fix it once at the data ingestion boundary:

Option A — Fix in getString() helper (line 57-60 of the conversation route):

function unescapeCStyleString(s: string): string {
  return s.replace(/\\([nrtv0'"\\])/g, (_, ch) => {
    const map: Record<string, string> = {
      n: '\n', r: '\r', t: '\t', v: '\v',
      '0': '\0', "'": "'", '"': '"', '\\': '\\',
    };
    return map[ch] ?? ch;
  });
}

function getString(span: SigNozListItem, key: string, fallback = ''): string {
  const v = getField(span, key);
  const raw = typeof v === 'string' ? v : v == null ? fallback : String(v);
  return unescapeCStyleString(raw);
}

This is the cleanest approach because it fixes the problem at the boundary where SigNoz data enters our system. All downstream consumers (timeline items, panel content, any future components) would get properly unescaped strings. Then the two .replaceAll('\\n', '\n') workarounds in timeline-item.tsx:86 and render-panel-content.tsx:264 can be removed.

Risk: This would unescape all string attributes, not just message content. For most attributes (span IDs, agent names, timestamps) this is a no-op since they don't contain escape sequences. But worth verifying that no attribute intentionally stores literal \n text.

Option B — If you want to be more targeted, apply unescapeCStyleString only when building the messageContent field in the ActivityItem mapping (line 1668):

messageContent: unescapeCStyleString(getString(span, SPAN_KEYS.MESSAGE_CONTENT, '')),

This is safer but means you'd need to add it to every string field that could contain user-authored text.

@claude the content though for my spans for ai assistant response look fine though, the text looks right with all the right line breaks

Claude finished @robert-inkeep's task in 3m 26s —— View job

Investigating span content encoding for AI assistant responses

• Gather context — read the relevant code files
• Analyze the data flow from span attributes to UI rendering
• Provide findings

Good observation — that's actually useful for narrowing down where the escaping happens. Here's what I found:

Both message.content (user messages) and ai.response.content (AI responses) follow the exact same path:

• Both are set as plain text strings on span attributes in the API (chat.ts:324, executionHandler.ts:509)
• Both are queried from SigNoz with the same STRING_TAG field config (lines 517 and 603 in the conversation route)
• Both are read back via the same getString() helper (lines 1668 and 1699)

If your spans show the right line breaks in SigNoz's own UI, that confirms the escaping is not in ClickHouse storage — it's happening somewhere in the SigNoz API response → our conversation route pipeline. The previous analysis attributing it to ClickHouse was likely wrong.

Why AI assistant responses look fine in the traces UI despite the same escaping: they're rendered through <Streamdown> (a markdown component) in both timeline-item.tsx:317 and render-panel-content.tsx:104, which likely handles the literal \n sequences. User messages render as raw text ({messageContent?.replaceAll('\\n', '\n')} at timeline-item.tsx:86), hence the band-aid.

The recommendation from the prior analysis still holds — fix it once at the getString() boundary with a proper C-style unescape function, and remove the scattered .replaceAll('\\n', '\n') calls. This would correctly handle \t, \r, etc. too.

The remaining question is whether the escaping is:

1. In the SigNoz API response format (likely — ClickHouse JSON output format escapes string values)
2. In the axios/JSON parsing layer

You could verify by logging the raw axios response for a conversation that has newlines in message.content to see exactly what comes back from the SigNoz API.