mirror of
https://github.com/openclaw/openclaw.git
synced 2026-05-28 08:12:12 +00:00
fb61de8c88
* fix(gemini): strip sub-second precision from web_search time_range_filter Gemini's google_search.time_range_filter rejects any non-zero fractional seconds with "[FIELD_INVALID] Granularity of nano is not supported", even though the underlying google.protobuf.Timestamp type accepts 0/3/6/9 fractional digits per its public spec. The grounding endpoint enforces a stricter rule than the underlying type. Date.prototype.toISOString() always emits millisecond precision, so every freshness call (and any date_after/date_before call hitting the "now" fallback for endTime) failed with the above 400 after #66498's fix shipped in 2026.5.19. Introduce toGeminiTimeRangeTimestamp() which strips the fractional-second component before serializing, and route all four timeRangeFilter timestamp sites through it. isoDateExclusiveEnd happens to produce all-zero fractional today (so Gemini accepts it), but routing it through the helper keeps the contract uniform and resilient to future changes. Why this slipped past the original CI: the existing freshness test used vi.setSystemTime(new Date("2026-04-15T12:00:00Z")), which always serializes back as ".000Z" — the one fractional form Gemini happens to accept. Wall-clock new Date() in production always has non-zero ms. The new test uses setSystemTime(new Date("2026-04-15T12:00:00.123Z")) to exercise the realistic case. Verified empirically against the live Gemini REST API: ".123Z" → 400 "Granularity of nano is not supported" ".000Z" → grounded content (the one fractional form accepted) "Z" → grounded content Fixes #85061. * test(gemini): use realistic non-zero ms in existing freshness test The original test set the fake clock to a moment with zero fractional seconds, so toISOString() produced ".000Z" — the one fractional form Gemini's google_search.time_range_filter happens to accept. Wall-clock new Date() in production produces non-zero ms, which Gemini rejects. Bumping the fake time to .123Z makes the existing test exercise the realistic case alongside the dedicated regression test. --------- Co-authored-by: Noah R <Noerr@users.noreply.github.com>