[Detail Bug] Maps SDK: UserLocation allows invalid coordinates and formats small values in scientific notation

[detail-app]

Detail Bug Report

https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_1ebe3ea2-7b82-4317-8689-0b4339e5168e

Summary

• Context: UserLocation is a domain model record used to represent a geographic hint (latitude and longitude) in Apple Maps Server API requests such as search, geocode, and autocomplete.
• Bug: The static factory method fromLatitudeLongitude fails to validate that coordinates are within valid ranges or are finite values, and it uses Double.toString() which can produce scientific notation (e.g., 1.0E-7) that is generally not supported by REST APIs for geographic coordinates.
• Actual vs. expected: UserLocation.fromLatitudeLongitude(1000, 1000) successfully creates an object with invalid coordinates, and fromLatitudeLongitude(0.0000001, 0.0000001) produces the string "1.0E-7,1.0E-7". Expected behavior is to throw IllegalArgumentException for invalid coordinates (as DirectionsEndpoint does) and to use a standard decimal format for all coordinates.
• Impact: Invalid coordinates propagate to the API causing 400 errors that could have been caught early, and high-precision coordinates close to 0 can cause requests to fail due to scientific notation formatting.

Code with Bug

public static UserLocation fromLatitudeLongitude(
    double latitude,
    double longitude
) {
    return new UserLocation(formatCoordinatePair(latitude, longitude)); // <-- BUG 🔴 Missing Location.validateLatitudeLongitude(latitude, longitude)
}

private static String formatCoordinatePair(
    double latitude,
    double longitude
) {
    return (
        Double.toString(latitude) + // <-- BUG 🔴 Produces scientific notation like "1.0E-7" for small values
        COORDINATE_SEPARATOR +
        Double.toString(longitude)
    );
}

Explanation

UserLocation.fromLatitudeLongitude directly formats and stores the coordinate pair without calling the shared coordinate validation logic used elsewhere (e.g., DirectionsEndpoint). This allows out-of-range/invalid lat/long values (and non-finite doubles) to reach request construction.

Additionally, Double.toString() can emit scientific notation for small values; when this string is used as a query parameter, the API may reject it.

Codebase Inconsistency

A validation pattern exists elsewhere in the codebase (notably in DirectionsEndpoint), but UserLocation does not apply it, despite representing the same lat/long concept.

Recommended Fix

Call shared validation before constructing the record, and format coordinates using a decimal-safe formatter (non-scientific), e.g. String.format(Locale.ROOT, "%.10f,%.10f", ...) with optional trimming of trailing zeros.

History

This bug was introduced in commit 33eca2a. These domain records were part of the initial model implementation and used Double.toString() for coordinate formatting, which produces scientific notation for small values, and lacked validation for coordinate ranges and raw string input—issues that were later missed when other models were updated with validation standards.