fix(llma): tolerate null numeric values in OTLP JSON ingestion

[richardsolomou]

Problem

PostHog's OTEL ingestion endpoint (/i/v0/ai/otel) returns 400 when receiving OTLP/JSON payloads containing null-valued scalar attributes like {"doubleValue": null}. The Vercel AI SDK emits these for cost/token metrics on partial stream chunks. The opentelemetry-proto crate types doubleValue as f64 (non-optional), so serde_json::from_value rejects the null with:

Invalid OTLP trace format: invalid type: null, expected f64

Changes

Extends patch_otel_json in rust/capture/src/otel/ingestion.rs to strip null-valued OTLP scalar fields (doubleValue, intValue, stringValue, boolValue, bytesValue) from AnyValue objects before deserialization. In protobuf-JSON encoding, a missing key is equivalent to an unset scalar, so removal is semantically correct — no coercion to default values.

The existing {} → null patching (for opentelemetry-rust#1253) is preserved as a special case of the same logic.

How did you test this code?

I am an agent and have not tested this manually. Automated testing:

• Added test_patch_otel_json_null_scalar_attrs: verifies {"doubleValue": null} and {"intValue": null} are stripped to Value::Null while {"stringValue": "gpt-4"} is preserved
• Added test_parse_json_with_null_double_attr: verifies the full pipeline (JSON parse → patch → deserialize into ExportTraceServiceRequest) succeeds with a null doubleValue attribute
• All 31 otel tests pass, clippy clean, fmt clean

Publish to changelog?

no

Docs update

N/A

🤖 LLM context

Agent-authored PR. Single-file change to rust/capture/src/otel/ingestion.rs — extends the existing JSON patching helper to handle a second class of OTLP/Rust type mismatch (null scalars in addition to empty objects).

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

This is a comment left during a code review.
Path: rust/capture/src/otel/ingestion.rs
Line: 258-277

Comment:
**Prefer parameterised test for null scalar types**

The test hard-codes `doubleValue` and `intValue` but leaves `stringValue`, `boolValue`, and `bytesValue` untested for the null case. Per the project's preference for parameterised tests, and to give a clear failure message per variant, consider iterating over all five scalar types:

```rust
#[test]
fn test_patch_otel_json_null_scalar_attrs() {
    for field in &["doubleValue", "intValue", "stringValue", "boolValue", "bytesValue"] {
        let mut v = serde_json::json!({"value": {}});
        v["value"].as_object_mut().unwrap().insert(field.to_string(), Value::Null);
        patch_otel_json(&mut v);
        assert_eq!(v["value"], Value::Null, "field `{field}` with null should be stripped");
    }

    // non-null scalar must be preserved
    let mut v = serde_json::json!({"value": {"stringValue": "gpt-4"}});
    patch_otel_json(&mut v);
    assert_eq!(v["value"]["stringValue"], "gpt-4");
}
```

This also guards against future regressions if a new scalar type is added to the stripping list.

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

_{Reviews (1): Last reviewed commit: "fix(llma): tolerate null numeric values ..." | Re-trigger Greptile}

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-04-14 11:49 UTC	Run
prod-us	✅ Deployed	2026-04-14 12:55 UTC	Run
prod-eu	✅ Deployed	2026-04-14 12:57 UTC	Run