floci-io/floci · error · CoercingParseValueException
AWSTimestamp out of range: {}
Error message
AWSTimestamp out of range: {} What it means
Thrown by the AWSTimestamp scalar's parseValue when the integer falls outside the allowed epoch-seconds window [0, 32503680000] (year 1 to year 3000 CE). AppSync defines AWSTimestamp as a numeric scalar with that validity range, and the emulator enforces it after converting the input to a long.
Source
Thrown at src/main/java/io/github/hectorvent/floci/services/appsync/graphql/scalars/AppSyncScalars.java:153
.build();
public static final GraphQLScalarType AWS_TIMESTAMP = GraphQLScalarType.newScalar()
.name("AWSTimestamp")
.description("Unix epoch seconds (0 to 32503680000)")
.coercing(new Coercing<Long, Long>() {
@Override
public Long serialize(Object dataFetcherResult) {
if (dataFetcherResult == null) return null;
if (dataFetcherResult instanceof Number n) return n.longValue();
return Long.parseLong(dataFetcherResult.toString());
}
@Override
public Long parseValue(Object input) {
long val;
if (input instanceof Number n) val = n.longValue();
else val = Long.parseLong(input.toString());
if (val < 0 || val > 32503680000L)
throw new CoercingParseValueException("AWSTimestamp out of range: " + val);
return val;
}
@Override
public Long parseLiteral(Object input) {
if (input instanceof graphql.language.IntValue iv) return parseValue(iv.getValue().longValue());
throw new CoercingParseLiteralException("AWSTimestamp must be an integer");
}
})
.build();
private static final Pattern EMAIL_PATTERN = Pattern.compile("^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,}$");
public static final GraphQLScalarType AWS_EMAIL = GraphQLScalarType.newScalar()
.name("AWSEmail")
.description("An RFC 5322 email address")
.coercing(new Coercing<String, String>() {
@Override
public String serialize(Object dataFetcherResult) {View on GitHub (pinned to 62ff490619)
Solutions
- Send epoch SECONDS: Instant.now().getEpochSecond(), never System.currentTimeMillis()
- If you have millis, divide by 1000: millis / 1000
- Clamp sentinels: use null or omit the field instead of -1 for 'no value'
- Validate client-side: 0 <= v && v <= 32503680000L
Example fix
// before long ts = System.currentTimeMillis(); // 1.7e12 -> out of range // after long ts = Instant.now().getEpochSecond(); // ~1.7e9, in range
Defensive patterns
Strategy: type-guard
Validate before calling
static boolean validAwsTimestamp(long v) { return v >= 0 && v <= 32503680000L; }
long ts = Instant.now().getEpochSecond();
if (!validAwsTimestamp(ts)) throw new IllegalArgumentException("timestamp must be epoch seconds in [0, 32503680000]"); Type guard
const isAwsTimestamp = (v: number): boolean => Number.isInteger(v) && v >= 0 && v <= 32503680000;
Try / catch
catch (CoercingParseValueException e) { // usually a millis/seconds mixup: divide by 1000 and retry once } Prevention
- Standardize on epoch seconds everywhere in the client
- Wrap System.currentTimeMillis() callers: timestamp = millis / 1000
- Never use -1 sentinels for AWSTimestamp — omit the field instead
When it happens
Trigger: A GraphQL request sends a negative epoch (e.g. -1), an epoch in milliseconds (e.g. 1705315800000 which is > 32503680000 and thus out of range for seconds), or a far-future value beyond year 3000 as an AWSTimestamp variable.
Common situations: Mixing up epoch milliseconds and epoch seconds — millis values exceed the ceiling immediately; clock skew or an uninitialized long (0 is fine but -1 from an error code is not); garbage values from uninitialized numeric fields or a default -1 sentinel.
Related errors
- AWSTimestamp must be an integer
- BadRequestException
- Invalid JSON: {}
- Invalid AWSDateTime: {}
- Invalid AWSDate: {}
AI-assisted analysis of floci-io/floci@62ff490619 (2026-08-14).
Data as JSON: /api/errors/7c80b25eb74b32b8.
Report an issue: GitHub.