When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

• Where: Timeline item component in conversation detail view

• Steps to reproduce:

  1. Navigate to a conversation detail page at /{tenantId}/projects/{projectId}/traces/conversations/{conversationId}
  2. Inspect any timeline item's <time> element
  3. Check the dateTime attribute value

• What failed: The <time dateTime={isoDateTime}> attribute contains a non-ISO-8601 string (e.g., 'Sun Mar 01 2026 22:30:00 GMT+0000') instead of ISO format (e.g., '2026-03-01T22:30:00.000Z'). This breaks accessibility and SEO machine-readability requirements for the dateTime attribute.

• Code analysis: Examined timeline-item.tsx where the timestamp is formatted. Line 228 creates a Date object that is passed directly to the dateTime attribute, which React converts to a non-ISO string via toString().

• Relevant code:

  agents-manage-ui/src/components/traces/timeline/timeline-item.tsx (lines 227–228)

  const formattedDateTime = formatDateTime(activity.timestamp, { local: true });
  const isoDateTime = new Date(activity.timestamp);

  agents-manage-ui/src/components/traces/timeline/timeline-item.tsx (lines 600–606)

  <time
    className="text-xs mb-2 inline-block text-gray-500 dark:text-white/50"
    dateTime={isoDateTime}
    title={formattedDateTime}
  >
    {formattedDateTime}
  </time>

• Why this is likely a bug: The PR changed line 228 from .toISOString() to just new Date(). The HTML <time> element's dateTime attribute must contain a machine-readable ISO 8601 string for accessibility tools and search engines to parse correctly. Passing a Date object causes React to call .toString() which produces a locale-dependent, non-ISO format.

• Introduced by this PR: Yes – this PR modified the relevant code (changed new Date(activity.timestamp).toISOString() to new Date(activity.timestamp))

• Timestamp: 16:35

• Where: SigNoz proxy route in agents-manage-ui

• Steps to reproduce:

  1. Send a POST request to /api/signoz?tenantId=default with a payload containing compositeQuery.queryType: 'builder' and compositeQuery.builderQueries instead of chQueries
  2. Observe the response status code

• What failed: The old builderQueries format was accepted with HTTP 200 instead of being rejected with HTTP 400. The Zod schema in route.ts requires chQueries, but this validation only applies at the Next.js layer. The agents-api signoz.ts route has no Zod validation and passes any payload directly to SigNoz.

• Code analysis: Examined agents-manage-ui/src/app/api/signoz/route.ts (Zod schema at lines 14-18) and agents-api/src/domains/manage/routes/signoz.ts (no schema validation). The Next.js route validates payloads, but requests can potentially reach agents-api through other paths or the schema can be bypassed.

• Relevant code:

  agents-manage-ui/src/app/api/signoz/route.ts (lines 14–18)

  const compositeQuerySchema = z.object({
    queryType: z.string(),
    panelType: z.string(),
    chQueries: z.record(z.string(), z.any()),
  });

  agents-api/src/domains/manage/routes/signoz.ts (lines 14–16)

  app.post('/query', async (c) => {
    let payload = await c.req.json();
    const requestedProjectId = payload.projectId;

• Why this is likely a bug: The PR migrated from builderQueries to chQueries format but did not add validation at the agents-api layer to reject the old format. This creates inconsistent behavior where the old format may still work depending on the request path.

• Introduced by this PR: Yes – this PR introduced the chQueries migration but did not add schema enforcement at agents-api

• Timestamp: 25:07

• Where: SigNoz proxy route in agents-api

• Steps to reproduce:

  1. Send a POST request to /api/signoz?tenantId=default with compositeQuery.queryType: 'builder' and compositeQuery.builderQueries
  2. Observe that the request is accepted (200 OK)

• What failed: Builder-format payloads are accepted without validation. While enforceQuerySecurity injects variables.tenant_id, builder-format queries in SigNoz do not use {{.variable}} substitution syntax. This means the injected tenant_id variable may have no effect on query scoping for builder-format queries, potentially allowing tenant isolation bypass.

• Code analysis: Examined agents-api/src/utils/signozHelpers.ts which only injects variables. It does not validate the query format or reject builder queries. Builder queries use a different filtering mechanism (filters.items array) that the old enforceSecurityFilters function handled, but the new enforceQuerySecurity function does not.

• Relevant code:

  agents-api/src/utils/signozHelpers.ts (lines 1–18)

  /**
   * Enforce tenant/project security on ClickHouse SQL queries by injecting
   * server-side variables. SQL queries use {{.tenant_id}} / {{.project_id}}
   * via SigNoz variable substitution, preventing SQL injection.
   *
   * Always overrides client-provided values to prevent spoofing.
   */
  export function enforceQuerySecurity(payload: any, tenantId: string, projectId?: string): any {
    const modifiedPayload = JSON.parse(JSON.stringify(payload));
    if (!modifiedPayload.variables) {
      modifiedPayload.variables = {};
    }
    modifiedPayload.variables.tenant_id = tenantId;
    if (projectId) {
      modifiedPayload.variables.project_id = projectId;
    }
    return modifiedPayload;
  }

• Why this is likely a bug: The new enforceQuerySecurity function assumes all queries use ClickHouse SQL with {{.tenant_id}} variable substitution. Builder-format queries do not use this mechanism and are not filtered. An attacker could craft builder-format queries that bypass tenant isolation. Defense-in-depth via SigNoz API key scoping provides partial mitigation, but this is a security regression from the previous implementation which handled both formats.

• Introduced by this PR: Yes – this PR removed the builder-format filter logic from enforceSecurityFilters and replaced it with enforceQuerySecurity which only handles ClickHouse SQL queries

• Timestamp: 25:27

Screen Recording

• Where: Span detail API endpoint /api/signoz/spans/[spanId]

• Steps to reproduce:

  1. Call GET /api/signoz/spans/nonexistent-span-id?conversationId=test-conv&tenantId=default
  2. Observe the HTTP response status code

• What failed: Expected 404 "Span not found" but received 500 Internal Server Error. When SigNoz is unreachable or returns an error, the endpoint catches all errors and returns 500 without distinguishing between "span not found" and "service unavailable" scenarios.

• Code analysis: The span detail endpoint at agents-manage-ui/src/app/api/signoz/spans/[spanId]/route.ts has proper 404 handling when the query succeeds but returns no results (lines 114-121). However, the catch block at lines 143-145 returns 500 for ALL errors without distinguishing connection errors (which should be 503) from other failures.

• Relevant code:

  agents-manage-ui/src/app/api/signoz/spans/[spanId]/route.ts (lines 113-146)

    const series = result?.series;
  
    if (!series || series.length === 0) {
      return NextResponse.json({ error: 'Span not found' }, { status: 404 });
    }
    // ... span parsing code ...
  
  } catch (error) {
    const errorMessage = error instanceof Error ? error.message : 'Failed to fetch span details';
    return NextResponse.json({ error: errorMessage }, { status: 500 });
  }

• Why this is likely a bug: The catch block does not differentiate between connection errors (ECONNREFUSED should return 503), authentication errors (should return 502), and actual failures. The conversation endpoint at conversations/[conversationId]/route.ts:1151-1177 correctly handles these cases with proper status codes, but the spans endpoint does not follow the same pattern.

• Introduced by this PR: No – pre-existing bug (the spans endpoint error handling was not modified in this PR, only the tenant_id filter was added at line 73)

• Timestamp: 101:30

• Where: SigNoz proxy endpoint /api/signoz (POST)

• Steps to reproduce:

  1. Ensure SigNoz is not running (port 3080 unreachable)
  2. Navigate to /default/stats and observe network requests
  3. Check the HTTP status codes returned by POST /api/signoz requests

• What failed: Expected 503 Service Unavailable when SigNoz is unreachable, but received 500 Internal Server Error. The error handling does not distinguish between a downstream service being unreachable and an internal application error.

• Code analysis: The agents-api correctly returns 503 for ECONNREFUSED errors (see agents-api/src/domains/manage/routes/signoz.ts:103-111). However, when SigNoz returns 401/403 authentication errors, the agents-api returns 500 (lines 113-122), and the manage-ui proxy at agents-manage-ui/src/app/api/signoz/route.ts:68-86 passes through the 500 status without mapping it to the appropriate service unavailability code.

• Relevant code:

  agents-api/src/domains/manage/routes/signoz.ts (lines 101-143)

  } catch (error) {
    if (axios.isAxiosError(error)) {
      if (error.code === 'ECONNREFUSED' || error.code === 'ENOTFOUND') {
        logger.error({ error: error.message }, 'SigNoz service unavailable');
        return c.json(
          { error: 'Service Unavailable', message: 'SigNoz service is unavailable' },
          503
        );
      }
      if (error.response?.status === 401 || error.response?.status === 403) {
        logger.error({ status: error.response.status }, 'SigNoz authentication failed');
        return c.json(
          { error: 'Internal Server Error', message: 'SigNoz authentication failed' },
          500  // Should be 502 Bad Gateway for upstream auth failure
        );
      }
    }
    // Falls through to 500 for all other errors

  agents-manage-ui/src/app/api/signoz/route.ts (lines 68-86)

  function handleProxyError(error: unknown, logger: ReturnType<typeof getLogger>) {
    // ...
    if (axios.isAxiosError(error)) {
      const status = error.response?.status || 500;
      const message = error.response?.data?.message || error.message;
      return NextResponse.json({ error: 'Failed to query SigNoz', details: message }, { status });
    }
    // Does not distinguish service unavailability from internal errors

• Why this is likely a bug: When SigNoz authentication fails (401/403), the code returns 500 "Internal Server Error" which is semantically incorrect. An authentication failure with an upstream service should return 502 Bad Gateway. Additionally, the manage-ui proxy doesn't handle ECONNREFUSED and other connection errors to map them to 503, relying on the agents-api to do so. The inconsistent status codes make it harder for clients to understand whether the error is recoverable.

• Introduced by this PR: No – pre-existing bug (the error handling logic in signoz.ts and route.ts was not changed in this PR)

• Timestamp: 102:12

Screen Recording