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

  1. Send epoch SECONDS: Instant.now().getEpochSecond(), never System.currentTimeMillis()
  2. If you have millis, divide by 1000: millis / 1000
  3. Clamp sentinels: use null or omit the field instead of -1 for 'no value'
  4. 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

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


AI-assisted analysis of floci-io/floci@62ff490619 (2026-08-14). Data as JSON: /api/errors/7c80b25eb74b32b8. Report an issue: GitHub.