The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 7, 2026 6:41pm

PR Summary

Low Risk
Changes extend an existing integration with new optional APIs and form wiring; no auth or core execution path refactors. Hosted-key behavior for speed limits is unchanged (BYOK only).

Overview
Adds Nearby Places as a new Google Maps block operation backed by a google_maps_places_nearby tool (Places API searchNearby), with required radius, optional type filter, max results, rank preference, and region/language fields wired through the block and registry.

Places text search gains pageToken support for pagination. Speed limits exposes KPH/MPH via a dedicated speedUnits subblock mapped to the Roads API units param. Geolocate gets block inputs for home MCC/MNC that were already supported on the tool.

The block sets authMode: ApiKey, tightens numeric parsing for radius and related fields, scopes the shared Language field to relevant operations, and adds a find-places-nearby skill template. Elevation treats missing resolution as optional/null in types and output.

^{Reviewed by Cursor Bugbot for commit 4a680f3. Configure here.}

Greptile Summary

This PR validates the Google Maps block against live API docs, adds a new google_maps_places_nearby tool (Places API New searchNearby), and wires several previously unconnected parameters such as homeMobileCountryCode/homeMobileNetworkCode for geolocate and units for speed limits.

• New tool: places_nearby.ts implements a full Places API New searchNearby POST request with correct X-Goog-FieldMask header, proper body construction, and safe transformResponse handling.
• Block fixes: Adds authMode: AuthMode.ApiKey, pageToken for text-search pagination (with timing caveat in description), speedUnits dropdown, and NaN-safe parsing for radius, maxResultCount, homeMobileCountryCode, and homeMobileNetworkCode.
• Parameter routing: placeType is mapped to both type (for the legacy text-search tool) and includedTypes array (for the new nearby tool) in a single transform return, correctly isolating the two APIs.

Confidence Score: 4/5

Safe to merge for all new tool functionality; a pre-existing structural concern in the block's subblock list warrants a follow-up.

All seven tool files (new and modified) are correct: request construction, header handling, response transforms, and type definitions are well-formed. The block transform correctly parses string inputs to the expected number types with NaN guards throughout. The one open concern — two subblock entries sharing id: 'radius' with different required/mode metadata — was noted in a prior review round and remains unresolved; if the block rendering or form-state layer keys on id, the places_nearby radius field could silently inherit the places_search variant's mode: 'advanced' and non-required metadata, bypassing the intended UI guard for the mandatory field.

apps/sim/blocks/blocks/google_maps.ts — the duplicate radius subblock definition.

Important Files Changed

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant UI as Block UI
    participant Block as google_maps.ts (transform)
    participant Registry as Tool Registry
    participant NearbyTool as places_nearby.ts
    participant GoogAPI as Places API (New)

    UI->>Block: "operation=places_nearby, aqLatitude, aqLongitude, radius, placeType, rankPreference, maxResultCount"
    Note over Block: Parses aqLatitude→lat, aqLongitude→lng,<br/>radius→parseInt, maxResultCount→parseInt,<br/>placeType→includedTypes[]
    Block->>Registry: "tool=google_maps_places_nearby, {lat, lng, radius, includedTypes, rankPreference, ...}"
    Registry->>NearbyTool: invoke with merged params
    NearbyTool->>GoogAPI: "POST /v1/places:searchNearby<br/>X-Goog-Api-Key, X-Goog-FieldMask<br/>body: {locationRestriction:{circle:{center,radius}}, includedTypes, rankPreference, ...}"
    GoogAPI-->>NearbyTool: "{places:[{id, displayName, formattedAddress, location, rating, ...}]}"
    NearbyTool-->>Registry: "{success:true, output:{places:[{placeId, name, lat, lng, rating, ...}]}}"
    Registry-->>UI: output.places

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant UI as Block UI
    participant Block as google_maps.ts (transform)
    participant Registry as Tool Registry
    participant NearbyTool as places_nearby.ts
    participant GoogAPI as Places API (New)

    UI->>Block: "operation=places_nearby, aqLatitude, aqLongitude, radius, placeType, rankPreference, maxResultCount"
    Note over Block: Parses aqLatitude→lat, aqLongitude→lng,<br/>radius→parseInt, maxResultCount→parseInt,<br/>placeType→includedTypes[]
    Block->>Registry: "tool=google_maps_places_nearby, {lat, lng, radius, includedTypes, rankPreference, ...}"
    Registry->>NearbyTool: invoke with merged params
    NearbyTool->>GoogAPI: "POST /v1/places:searchNearby<br/>X-Goog-Api-Key, X-Goog-FieldMask<br/>body: {locationRestriction:{circle:{center,radius}}, includedTypes, rankPreference, ...}"
    GoogAPI-->>NearbyTool: "{places:[{id, displayName, formattedAddress, location, rating, ...}]}"
    NearbyTool-->>Registry: "{success:true, output:{places:[{placeId, name, lat, lng, rating, ...}]}}"
    Registry-->>UI: output.places

_{Reviews (5): Last reviewed commit: "fix(google-maps): guard radius NaN parse..." | Re-trigger Greptile}

Responding to Greptile's two "Comments Outside Diff" findings from the last review round:

1. Missing Number.isNaN guard on radius — fixed in 4a680f3. radius now guards NaN the same way days/maxResultCount/homeMobileCountryCode/homeMobileNetworkCode already do in this file, so a non-numeric radius no longer silently sends "radius":null to the required Nearby Search field.

2. Duplicate subblock id: 'radius' — verified this is a safe, established pattern already used elsewhere in this exact file (the pre-existing apiKey subblock is split the same way across two mutually-exclusive conditions), and in 9+ other blocks in the codebase (datagma, exa, firecrawl, leadmagic, image_generator, findymail, millionverifier, mistral_parse, vision). The conditions are collectively exhaustive and mutually exclusive per operation, so only one variant is ever visible/active at a time — no undefined behavior. No change made; keeping this consistent with the rest of the codebase.

@greptile review

@cursor review

Follow-up on the outstanding `radius` duplicate-id question (previous reply cited cross-block precedent; here's the code-level proof).

Traced the actual rendering path: `apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/hooks/use-editor-subblock-layout.ts:117` computes `visibleSubBlocks` via a plain array `.filter()` over `config.subBlocks`, evaluating each entry's `condition` against the current `operation` value (line 149-151, `evaluateSubBlockCondition`). This is not a `Record`/`Map` keyed by `id` — there is no dedup-by-key step anywhere in this path. Since the two `radius` entries have mutually exclusive conditions (`operation: 'places_search'` vs `operation: 'places_nearby'`), at most one can ever pass the filter for a given operation value, so `visibleSubBlocks` never contains two entries with the same `id` simultaneously — there's no scenario where the wrong variant's `required`/`mode` metadata could apply.

This confirms it structurally, not just by precedent: the pattern is safe by construction. No change made.

@greptile review

@cursor review

@greptile this exact concern was already addressed with code-level proof — see the reply at #5484 (comment) above, which traces the actual render path in apps/sim/app/workspace/[workspaceId]/w/[workflowId]/components/panel/components/editor/hooks/use-editor-subblock-layout.ts:117. visibleSubBlocks is computed via a plain array .filter() (not a Record/Map keyed by id), and the two radius entries have mutually exclusive conditions on operation, so at most one is ever in the filtered array for a given operation. There is no id-keyed collapse anywhere in that path, so the required-field metadata for places_nearby's radius cannot be silently clobbered. Please re-review with this in mind.

@greptile review