Fixes#88528.
Gemini web_search now accepts successful Google Search grounding responses that include candidate text and an empty `groundingMetadata` object without `groundingChunks`, returning wrapped content with `citations: []` instead of throwing `Gemini API error: malformed JSON response`.
Proof: live direct Gemini API reproduced the empty-grounding response shape; live OpenClaw provider failed before and succeeded after; `node scripts/run-vitest.mjs extensions/google/web-search-provider.test.ts`; `pnpm lint:web-search-provider-boundaries`; targeted oxfmt check; `git diff --check`; autoreview clean.
CI note: admin bypass used for unrelated failures in memory-core/device-pair/scripts, an existing core architecture cycle, and gateway-watch; PR diff touched only the two Gemini files.
Fixes#87191. Keeps Brave and Gemini runtime-injected web search provider config readable by providers without re-exposing legacy tools.web.search provider objects to config validation.
* 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>
