[Bug]:traceStartTime ignores spans with exactly 0 timestamp in get_critical_path

[Rozerxshashank]

What happened?

As a developer, I want the get_critical_path tool to find the correct start time for a trace.
Right now, the code uses 0 as a default starting value to keep track of the earliest start time:

if traceStartTime == 0 || startTime < traceStartTime {
	traceStartTime = startTime
}

If a span actually starts at exactly 0 (which happens often in unit tests), traceStartTime becomes 0. When the code checks the next span (which starts later, e.g., at 100), the condition traceStartTime == 0 is true. This causes the code to overwrite the correct 0 value with the new 100 value. The system completely forgets that the trace started at 0.

Steps to reproduce

1. Create a mock trace with two spans.
2. Set the first span's start time to exactly 0.
3. Set the second span's start time to 100.
4. Run the get_critical_path tool on this trace.
5. See that the tool calculates the total time and offsets as if the trace started at 100 instead of 0.

Expected behavior

The code should keep 0 as the start time. To fix this, the default starting value should be set to the highest possible number (math.MaxUint64) instead of 0. This way, a real 0 timestamp is not overwritten.

Relevant log output

Screenshot

No response

Additional context

This bug was found in cmd/jaeger/internal/extension/jaegerquery/internal/mcptools/internal/handlers/get_critical_path.go.

Jaeger backend version

No response

SDK

No response

Pipeline

No response

Stogage backend

No response

Operating system

No response

Deployment model

No response

Deployment configs

[Rozerxshashank]

I've prepared a fix for this.