[Detail Bug] CLI: User-provided coordinates are not validated, allowing NaN/Infinity/out-of-range values into Apple Maps requests

[detail-app]

Detail Bug Report

https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_a47b5cd2-c0d7-4189-9e95-823d56b0693a

Introduced in #34 by @WilliamAGH on Jan 23, 2026

Summary

• Context: UserLocation.java:27-31 (fromLatitudeLongitude method)
• Bug: Method accepts invalid coordinates (NaN, Infinity, out-of-range) without validation, producing malformed query strings that violate the documented parameter contract
• Actual vs. expected: Invalid coordinates silently become malformed query strings (e.g., userLocation=NaN,Infinity) instead of throwing IllegalArgumentException at construction time
• Impact: Invalid CLI/env-var latitude/longitude values can propagate to Apple Maps API requests as malformed coordinates, failing late instead of failing fast with clear errors

Code with Bug

// UserLocation.java:27-31
public static UserLocation fromLatitudeLongitude(
    double latitude,
    double longitude
) {
    return new UserLocation(formatCoordinatePair(latitude, longitude)); // <-- BUG 🔴 missing validateLatitudeLongitude; accepts NaN/Infinity/out-of-range
}

Explanation

UserLocation.fromLatitudeLongitude() formats raw doubles into a query-string coordinate pair without calling Location.validateLatitudeLongitude(). As a result, values like NaN, Infinity, or latitude/longitude outside valid ranges are accepted and serialized into malformed request parameters (e.g., NaN,Infinity, 200.0,300.0).

This is inconsistent with the structurally identical DirectionsEndpoint.fromLatitudeLongitude(), which does validate and throws IllegalArgumentException for the same inputs.

Codebase Inconsistency

DirectionsEndpoint validates but UserLocation does not, despite both being in the same package and having access to the same package-private validator:

// DirectionsEndpoint.java:37-39
public static DirectionsEndpoint fromLatitudeLongitude(double latitude, double longitude) {
    Location.validateLatitudeLongitude(latitude, longitude);  // validates
    return new DirectionsEndpoint(formatCoordinatePair(latitude, longitude));
}

Additionally, the CLI parsing path uses Double.parseDouble(), which accepts IEEE-754 special values (NaN, Infinity), and passes those directly into UserLocation.fromLatitudeLongitude() (via env var and CLI flag), bypassing any other validation.

Failing Test

The added UserLocationValidationTest.java (mirroring existing validation tests for DirectionsEndpoint/Location) fails with 4 failures:

UserLocationValidationTest > rejectsInfiniteLongitude() FAILED
UserLocationValidationTest > rejectsNaNLatitude() FAILED
UserLocationValidationTest > rejectsLongitudeBelowRange() FAILED
UserLocationValidationTest > rejectsLatitudeAboveRange() FAILED

After applying the recommended fix, the build passes:

BUILD SUCCESSFUL in 3s

Recommended Fix

public static UserLocation fromLatitudeLongitude(double latitude, double longitude) {
    Location.validateLatitudeLongitude(latitude, longitude);
    return new UserLocation(formatCoordinatePair(latitude, longitude));
}

History

This bug was introduced in commit f83c5e2. The commit added coordinate validation to Location.validateLatitudeLongitude() and applied it to DirectionsEndpoint.fromLatitudeLongitude(), but failed to apply the same validation to the identically-structured UserLocation.fromLatitudeLongitude() method.