fix(tracing): calculate traceid in python not clickhouse to avoid nullable checks

[frankh]

Problem

hogql was wrapping the clickhouse comparison in ifNull checks, which breaks clickhouse's index analysis

assumeNotNull did not fix this - instead calculate in python so it's a constant check which should avoid the ifNull check

Changes

How did you test this code?

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Publish to changelog?

Docs update

[greptile-apps]

Comments Outside Diff (1)

1. products/tracing/backend/presentation/views.py, line 51 (link)

   query endpoint missing traceId validation

   The trace endpoint now validates trace_id with a try/except (lines 87–91), but the query endpoint passes traceId from the request body directly to TraceSpansQuery without any equivalent validation. When logic.py then calls bytes.fromhex(self.query.traceId) at line 179, an invalid hex string (e.g. "xyz123") will raise an unhandled ValueError, resulting in a 500 error instead of a 400.

   Before this PR, the raw hex was passed as a ClickHouse constant to unhex(), which would silently return empty bytes for invalid input. The migration to Python-side conversion introduces this new failure path.

   Consider adding the same validation guard to the query action:

   traceId = query_data.get("traceId", None)
   if traceId:
       try:
           bytes.fromhex(traceId)
       except ValueError:
           return Response({"error": "Invalid traceId"}, status=status.HTTP_400_BAD_REQUEST)

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: products/tracing/backend/presentation/views.py
   Line: 51
   
   Comment:
   **`query` endpoint missing `traceId` validation**
   
   The `trace` endpoint now validates `trace_id` with a `try/except` (lines 87–91), but the `query` endpoint passes `traceId` from the request body directly to `TraceSpansQuery` without any equivalent validation. When `logic.py` then calls `bytes.fromhex(self.query.traceId)` at line 179, an invalid hex string (e.g. `"xyz123"`) will raise an unhandled `ValueError`, resulting in a 500 error instead of a 400.
   
   Before this PR, the raw hex was passed as a ClickHouse constant to `unhex()`, which would silently return empty bytes for invalid input. The migration to Python-side conversion introduces this new failure path.
   
   Consider adding the same validation guard to the `query` action:
   
   ```python
   traceId = query_data.get("traceId", None)
   if traceId:
       try:
           bytes.fromhex(traceId)
       except ValueError:
           return Response({"error": "Invalid traceId"}, status=status.HTTP_400_BAD_REQUEST)
   ```
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: products/tracing/backend/presentation/views.py
Line: 51

Comment:
**`query` endpoint missing `traceId` validation**

The `trace` endpoint now validates `trace_id` with a `try/except` (lines 87–91), but the `query` endpoint passes `traceId` from the request body directly to `TraceSpansQuery` without any equivalent validation. When `logic.py` then calls `bytes.fromhex(self.query.traceId)` at line 179, an invalid hex string (e.g. `"xyz123"`) will raise an unhandled `ValueError`, resulting in a 500 error instead of a 400.

Before this PR, the raw hex was passed as a ClickHouse constant to `unhex()`, which would silently return empty bytes for invalid input. The migration to Python-side conversion introduces this new failure path.

Consider adding the same validation guard to the `query` action:

```python
traceId = query_data.get("traceId", None)
if traceId:
    try:
        bytes.fromhex(traceId)
    except ValueError:
        return Response({"error": "Invalid traceId"}, status=status.HTTP_400_BAD_REQUEST)
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: products/tracing/backend/presentation/views.py
Line: 87-91

Comment:
**Redundant computation — result is discarded**

The full `base64.b64encode(bytes.fromhex(trace_id)).decode("ascii")` conversion is computed here purely for validation, but the result is thrown away. `logic.py` then performs the exact same computation again. This is a mild OnceAndOnlyOnce violation.

If you only need to verify the hex is valid, `bytes.fromhex(trace_id)` alone is sufficient — no need to do the base64 step:

```python
        try:
            bytes.fromhex(trace_id)
        except ValueError:
            return Response(status=status.HTTP_400_BAD_REQUEST)
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(tracing): calculate traceid in pytho..." | Re-trigger Greptile}

[greptile-apps]

Redundant computation — result is discarded

The full base64.b64encode(bytes.fromhex(trace_id)).decode("ascii") conversion is computed here purely for validation, but the result is thrown away. logic.py then performs the exact same computation again. This is a mild OnceAndOnlyOnce violation.

If you only need to verify the hex is valid, bytes.fromhex(trace_id) alone is sufficient — no need to do the base64 step:

        try:
            bytes.fromhex(trace_id)
        except ValueError:
            return Response(status=status.HTTP_400_BAD_REQUEST)

Prompt To Fix With AI

This is a comment left during a code review.
Path: products/tracing/backend/presentation/views.py
Line: 87-91

Comment:
**Redundant computation — result is discarded**

The full `base64.b64encode(bytes.fromhex(trace_id)).decode("ascii")` conversion is computed here purely for validation, but the result is thrown away. `logic.py` then performs the exact same computation again. This is a mild OnceAndOnlyOnce violation.

If you only need to verify the hex is valid, `bytes.fromhex(trace_id)` alone is sufficient — no need to do the base64 step:

```python
        try:
            bytes.fromhex(trace_id)
        except ValueError:
            return Response(status=status.HTTP_400_BAD_REQUEST)
```

How can I resolve this? If you propose a fix, please make it concise.