[Bug]: Out-of-range search timestamps cause trace summary requests to fail #4284

What happened?

A trace-summary search fails before making an API request when the search URL contains a timestamp that is finite and positive but outside JavaScript's supported Date range.

For example, this value passes the current numeric checks:

100000000000000000000

Converting it to an ISO timestamp throws:

RangeError: Invalid time value

This can be triggered by a malformed, manually edited, or corrupted shared search URL.

Steps to reproduce

1. Construct a trace search query with an out-of-range microsecond timestamp:

const query = {
  service: 'my-svc',
  operation: undefined,
  start: '100000000000000000000',
  end: '1700000060000000',
  limit: 20,
  lookback: 'custom',
};

2. Call:

client.fetchTraceSummaries(query);

3. Observe that the promise rejects with:

RangeError: Invalid time value

4. Observe that fetch() is never called.

The same behavior occurs independently when end contains an out-of-range value.

Expected behavior

Out-of-range timestamps should be handled as malformed URL parameters instead of being passed to Date.prototype.toISOString().

The API client should not throw an unexpected RangeError. Consistent with the existing comment in fetchTraceSummaries(), an invalid timestamp can be omitted from the generated request so malformed URL parameters are handled gracefully.

Relevant log output

RangeError: Invalid time value

Screenshot

Not applicable.

Additional context

The current validation checks only whether the converted value is finite and positive:

const startUs = Number(query.start);
const endUs = Number(query.end);

if (Number.isFinite(startUs) && startUs > 0)
  params.set('query.startTimeMin', new Date(startUs / 1000).toISOString());

if (Number.isFinite(endUs) && endUs > 0)
  params.set('query.startTimeMax', new Date(endUs / 1000).toISOString());

A finite number is not necessarily representable as a JavaScript Date.

A possible fix is to validate the constructed Date before calling toISOString(). Regression tests should cover out-of-range start and end values and verify that request construction does not throw.

I searched existing issues and pull requests for Invalid time value, out-of-range timestamps, timestamp overflow, toISOString, and fetchTraceSummaries, but did not find an existing report. I would be happy to submit a focused PR with regression tests if this behavior is confirmed.

Jaeger backend version

Not applicable; this occurs while Jaeger UI constructs the API v3 request.

SDK

Not applicable.

Pipeline

Not applicable.

Storage backend

Not applicable.

Operating system

Not applicable.

Deployment model

Not applicable.

Deployment configs

Not applicable.