Invalid Date reaches metadata rollup queries as "nan" Int64 param (BAD_QUERY_PARAMETER 457) #2933

Symptom

Occasional BAD_QUERY_PARAMETER (code 457) failures on the key-rollup discovery query, observed in a production tenant's query_log (found while investigating ClickHouse/support-escalation#8482):

Code: 457. DB::Exception: Value nan cannot be parsed as Int64 for query parameter 'HYPERDX_PARAM_78043'
because it isn't parsed completely: only 0 of 3 bytes was parsed: . (BAD_QUERY_PARAMETER)

SELECT Key FROM {db:Identifier}.{table:Identifier}
WHERE ColumnIdentifier = {col:String}
  AND Timestamp >= toStartOfFifteenMinutes(fromUnixTimestamp64Milli({HYPERDX_PARAM_78043:Int64})) ...

The literal string nan is bound as an Int64 date param — i.e. Date.getTime() returned NaN, meaning an Invalid Date reached getAlignedDateRange / the rollup query builders in packages/common-utils/src/core/metadata.ts (getMapKeys, getMetadataMVKeyValues).

Observed repeatedly (e.g. 2026-08-13 22:28/22:30/23:31, 2026-08-16 23:58 UTC on one tenant), always in pairs, always the same param-name hash (78043 = hash of nan).

Expected

An invalid/unparseable date range should never produce a ClickHouse query with nan params. Either:

1. Guard the metadata query paths: skip (or throw a descriptive client-side error) when dateRange contains an Invalid Date, and/or
2. Find and fix the upstream producer of the Invalid Date (likely a date-range parse from URL/live-tail state in the app).

Notes

• Low severity: the failure is caught and the affected facet fetch falls back / returns empty, but it burns a query, logs a confusing server-side error, and can mask real issues.
• Repro likely involves an invalid from/to URL param or a transient live-tail state on the search page.