Repository navigation
fix(routes): validate numeric inputs and sample wrapped polylines - #54
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs maintainer review before merge. Reviewed September 12, 2026, 11:20 PM ET / September 13, 2026, 03:20 UTC. ClawSweeper reviewWhat this changesThe PR rejects non-finite request numbers, validates encoded route coordinates, fixes date-line waypoint sampling and antipodal distance calculations, and adds regression tests and documentation. Merge readiness✅ Ready for maintainer review This remains a useful, focused fix: current main and v0.4.9 retain the reported defects. No introduced correctness or security defect was found, and collaborator-authored work is protected from automatic closure. Priority: P2 Review scores
Verification
How this fits togethergoplaces exposes Google Places and Routes workflows through a Go library and CLI. Route searches validate user inputs, decode Google's route geometry, and search for places near sampled waypoints. flowchart TD
A[CLI or Go request] --> B[Numeric validation]
B -->|Valid request| C[Google Routes response]
C --> D[Decode and validate geometry]
D --> E[Sample route waypoints]
E --> F[Google Places searches]
F --> G[Waypoint search results]
B -->|Invalid input| H[Validation error]
Before mergeNone. Agent review detailsSecurityNone. Review metrics
Technical reviewBest possible solution: Keep validation in the shared client helpers and geometry corrections in the route sampler, preserving valid-input defaults and distinguishing upstream errors from user validation failures. Do we have a high-confidence way to reproduce the issue? Yes, from source: NaN bypasses main's ordered comparisons, and interpolation between longitudes 179 and −179 selects longitude 0. The supplied body reports corresponding CLI failures; this review did not execute them. Is this the best way to solve the issue? Yes. The patch repairs existing validation and geometry owners without introducing competing APIs, settings, or dependencies, and covers the relevant rejection and sampling paths. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning medium; reviewed against 84fff29e4fd4. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
|
Numeric bounds checks using only
<and>let NaN through, so route search could call Routes before discovering an invalid radius. Polyline decoding also accepted invalid characters and coordinates, longitude interpolation crossed the long way around the globe, and antipodal roundoff could produce a NaN distance and panic during sampling.Share radius/coordinate validation across request types and reject non-finite ratings before HTTP. Decode both polyline dimensions through one bounded 32-bit decoder, validating characters and accumulated coordinates before sampling. Interpolate the short longitude crossing, treat ±180° as the same location, and clamp the haversine's roundoff at one. Malformed upstream data remains an API-processing error (exit 1); invalid user numbers now produce the existing validation class (exit 2). Update client and route documentation plus Unreleased notes.
Regression tests first failed for all these root cases. Go 1.26.8 race tests, lint, and 92.3% coverage now pass. Isolated Codex autoreview is scoped-clean at P0–P2. The commit was rebased onto the merged security fix with an identical reviewed source tree.
Built-CLI proof against a synthetic local Routes/Places server:
All ten regression scenarios pass. The normal 21-case built-CLI comparison across all eight commands remains byte-identical to baseline, SHA-256
043a9aa35c7e9a159a75b42afed4e4d56bf606646ee1352e3a22e8af3185eefe. No Google credentials or external API calls are used for this proof.