quarkusio/quarkus · error · IllegalArgumentException
The longitude must be in [-180, 180]
Error message
The longitude must be in [-180, 180]
What it means
Validation.validateLongitude is a pre-flight argument check used by the Quarkus Redis datasource before sending GEO commands (GEOADD, GEOSEARCH, etc.) to Redis. Redis geospatial operations encode coordinates with a finite valid range, so a longitude outside [-180, 180] is rejected locally with IllegalArgumentException instead of producing an opaque server-side error.
Source
Thrown at extensions/redis-client/runtime/src/main/java/io/quarkus/redis/runtime/datasource/Validation.java:103
throw new IllegalArgumentException("`" + name + "` must not be `null`");
}
if (col.size() == 0) {
throw new IllegalArgumentException("`" + name + "` must not be empty");
}
}
static <K, V> void notNullOrEmpty(Map<K, V> map, String name) {
if (map == null) {
throw new IllegalArgumentException("`" + name + "` must not be `null`");
}
if (map.size() == 0) {
throw new IllegalArgumentException("`" + name + "` must not be empty");
}
}
static void validateLongitude(double longitude) {
if (longitude < -180 || longitude > 180) {
throw new IllegalArgumentException("The longitude must be in [-180, 180]");
}
}
static void validateLatitude(double latitude) {
if (latitude < -85.05112878 || latitude > 85.05112878) {
throw new IllegalArgumentException("The latitude must be in [85.05112878, 85.05112878]");
}
}
public static void validateTimeout(Duration value, String name) {
if (value == null) {
throw new IllegalArgumentException(String.format("`%s` must not be `null`", name));
}
if (value.isNegative()) {
throw new IllegalArgumentException(String.format("`%s` must be greater than or equal to zero", name));
}
}
View on GitHub (pinned to e1c734241f)
Solutions
- Clamp or validate the longitude into [-180, 180] before calling the Redis geo API
- Check that longitude and latitude arguments are not swapped (longitude comes first in the API)
- Convert any DMS (degrees/minutes/seconds) coordinates to decimal degrees before the call
- Normalize out-of-range values with wrapping ((lon + 180) % 360 + 360) % 360 - 180 if wraparound is semantically acceptable
Example fix
// before
redis.geoadd("cities", -190.5, 45.5, "paris");
// after
double lon = Math.max(-180, Math.min(180, -190.5)); // or fix the source data
redis.geoadd("cities", lon, 45.5, "paris"); Defensive patterns
Strategy: validation
Validate before calling
if (lon < -180 || lon > 180) throw new IllegalArgumentException("longitude out of range: " + lon);
double normalized = ((lon + 180) % 360 + 360) % 360 - 180; // wrap if acceptable Try / catch
try { redis.geoadd(key, lon, lat, member); } catch (IllegalArgumentException e) { log.warn("Bad coordinate: {}", e.getMessage()); } Prevention
- Validate coordinates at data-ingestion time
- Keep longitude first in mind: API order is (longitude, latitude)
- Store coordinates as decimal degrees only
- Add unit tests for boundary values -180, 0, 180
When it happens
Trigger: Calling any geo API on a RedisDataSource / ReactiveRedisDataSource (e.g. geoadd(key, longitude, latitude, member), geosearch, geopos inputs) with a hardcoded or computed longitude value less than -180 or greater than 180, often from mixed DMS/decimal data or sign/order swaps of lat/lng.
Common situations: Swapping latitude and longitude when importing CSV/GPS data; using degrees-minutes-seconds without converting to decimal degrees; parsing '180.000001' from floating point accumulation; feeding raw GPS NMEA values.
Related errors
- The latitude must be in [85.05112878, 85.05112878]
- `count` must be strictly positive
- `timeout` must be positive
- `timeout` must not be `null`
- `timestamp` must not be `null`
AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05).
Data as JSON: /api/errors/5808b07ca5d60828.
Report an issue: GitHub.