An unreadable span timestamp becomes a real-looking duration in ingest_traces

[CaptainMittens]

Version

Built from source at ae5de7fe (main), release line v0.10.8

Platform

macOS (Apple Silicon)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

strtoll answers 0 for text it cannot read, and cbm_parse_duration hands that 0
straight into its subtraction:

int64_t start = strtoll(start_nano, NULL, CBM_DECIMAL_BASE);
int64_t end = strtoll(end_nano, NULL, CBM_DECIMAL_BASE);
return (end > start) ? (end - start) : 0;

The obvious harm is a false duration of zero: a span that genuinely took no time and a
span whose timestamps were garbage become the same row.

It is worse than that. An unreadable start time reads as 0, so the span reports the
whole end time as its duration. A test pinning this fails on unfixed code like so:

FAIL tests/test_traces.c:340: info.duration_ns == 1050000000,
  expected CBM_DURATION_UNKNOWN == -1

That is 1.05 seconds of measured time for a span whose start was never read, and nothing
downstream can tell that number from a real measurement.

I expected an unreadable timestamp to produce an explicit unknown rather than a plausible
duration.

Reproduction

1. Call ingest_traces with a span whose start_nano is unreadable — an empty string,
   null, or any non-numeric text — and a valid end_nano of, say, 1050000000.
2. Read the span back.
3. Result: duration_ns is 1050000000, indistinguishable from a real 1.05 s span.
   Expected: an explicit unknown, so a consumer can tell measured time from missing time.

The zero-duration case reproduces the same way with both timestamps unreadable.

Logs

No error is emitted — the unreadable timestamp is accepted as 0.

Diagnostics trajectory (memory / performance / leak issues)

Not applicable — a correctness issue, not memory or performance.

Project scale (if relevant)

Reproduces at any scale.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.