[Detail Bug] Maps: Some coordinate query parameters are not URL-encoded (inconsistent RFC 3986 compliance)

[detail-app]

Detail Bug Report

https://app.detail.dev/org_befd6425-a158-4e24-9d4d-1e5c08769515/bugs/bug_1c309eba-1903-46a7-becc-fa90b4e4baf2

Introduced in 84b4c69 by @WilliamAGH on Jan 15, 2026

Summary

• Context: DirectionsInput.toQueryString() builds query strings for Apple Maps directions API.
• Bug: RouteLocation parameters receive different encoding treatment across the codebase—encoded in EtaInput, unencoded in DirectionsInput. Within DirectionsInput, coordinate strings are encoded differently based on parameter name, not value type.
• Actual vs. expected: Actual: within the same query string, destination=37.3349%2C-122.009 (encoded) but searchLocation=37.78,-122.42 (NOT encoded). Expected: consistent encoding of coordinate-producing parameters per the project’s RFC 3986 standard (commit f979830).
• Impact: Same type (RouteLocation) encoded inconsistently across files; same value format (coordinates with commas) encoded differently within single method; violates the project's RFC 3986 standard established in commit f979830.

Code with Bug

// DirectionsInput.java - toQueryString() method

// These ARE encoded:
parameters.add(formatParameter(PARAMETER_ORIGIN, encode(origin.toQueryString())));
parameters.add(formatParameter(PARAMETER_DESTINATION, encode(destination.toQueryString())));

// These are NOT encoded:
searchLocation.ifPresent(searchLocationInput ->
    parameters.add(formatParameter(PARAMETER_SEARCH_LOCATION, searchLocationInput.toQueryString()))); // <-- BUG 🔴 missing encode(), leaves commas/reserved chars unencoded
searchRegion.ifPresent(searchRegionInput ->
    parameters.add(formatParameter(PARAMETER_SEARCH_REGION, searchRegionInput.toQueryString()))); // <-- BUG 🔴 missing encode()
userLocation.ifPresent(userLocationInput ->
    parameters.add(formatParameter(PARAMETER_USER_LOCATION, userLocationInput.toQueryString()))); // <-- BUG 🔴 missing encode()

Explanation

• The project already has an encode() helper (URLEncoder.encode(rawText, StandardCharsets.UTF_8)) and uses it for some parameters in DirectionsInput (origin, destination).
• However, searchLocation, searchRegion, and userLocation are appended without encode(). When these values are coordinates (e.g., lat,lng), they include commas.
• This creates a clear inconsistency:
  • Across files: RouteLocation is encoded in EtaInput but not encoded in DirectionsInput.
  • Within the same method: coordinate pairs are sometimes encoded (destination) and sometimes not (searchLocation).
• Commit f979830 established/confirmed the project standard that reserved characters in query parameters should be RFC 3986-compliant (explicitly calling out commas in coordinates). DirectionsInput does not consistently apply that standard.

Codebase Inconsistency

// EtaInput.java - ENCODED:
parameters.add(formatParameter(PARAMETER_ORIGIN, encode(origin.toQueryString())));

This encodes a single RouteLocation (no pipe concatenation), demonstrating the intent is to encode coordinate commas as well, not only list separators.

Recommended Fix

Apply encode() to all coordinate-producing parameters:

searchLocation.ifPresent(searchLocationInput ->
    parameters.add(formatParameter(PARAMETER_SEARCH_LOCATION, encode(searchLocationInput.toQueryString()))));
searchRegion.ifPresent(searchRegionInput ->
    parameters.add(formatParameter(PARAMETER_SEARCH_REGION, encode(searchRegionInput.toQueryString()))));
userLocation.ifPresent(userLocationInput ->
    parameters.add(formatParameter(PARAMETER_USER_LOCATION, encode(userLocationInput.toQueryString()))));

Update test expectations accordingly.

History

This bug was introduced in commit 84b4c69. The initial implementation of DirectionsInput.toQueryString() (and other Input classes) failed to URL-encode coordinate parameters containing commas, establishing the inconsistent pattern where RouteLocation values were passed raw. A subsequent fix (commit f979830) corrected EtaInput by wrapping coordinate parameters with encode(), but the same fix was never applied to DirectionsInput, GeocodeInput, SearchInput, or SearchAutocompleteInput, leaving the bug intact and creating the cross-file inconsistency.