floci-io/floci · error · CoercingParseValueException
Invalid AWSByte: not valid base64
Error message
Invalid AWSByte: not valid base64
What it means
The AWSByte GraphQL scalar in the AppSync emulator only accepts valid RFC 4648 base64 strings. parseValue decodes the incoming value with java.util.Base64 and throws graphql-java's CoercingParseValueException when decoding fails. This mirrors AWS AppSync, which rejects AWSByte variables/literals that are not valid base64 before the resolver runs.
Source
Thrown at src/main/java/io/github/hectorvent/floci/services/appsync/graphql/scalars/AppSyncScalars.java:457
}
})
.build();
public static final GraphQLScalarType AWS_BYTE = GraphQLScalarType.newScalar()
.name("AWSByte")
.description("A base64-encoded byte array")
.coercing(new Coercing<String, String>() {
@Override
public String serialize(Object dataFetcherResult) {
return dataFetcherResult != null ? dataFetcherResult.toString() : null;
}
@Override
public String parseValue(Object input) {
String str = input.toString();
try {
Base64.getDecoder().decode(str);
} catch (IllegalArgumentException e) {
throw new CoercingParseValueException("Invalid AWSByte: not valid base64");
}
return str;
}
@Override
public String parseLiteral(Object input) {
if (!(input instanceof StringValue sv)) return null;
return parseValue(sv.getValue());
}
})
.build();
private AppSyncScalars() {}
}
View on GitHub (pinned to 62ff490619)
Solutions
- Encode the value with standard base64 before sending: Base64.getEncoder().encodeToString(bytes) (Java) or Buffer.from(data).toString('base64') (Node).
- If the payload is URL-safe base64, convert it to standard base64 or re-encode the original bytes with the standard alphabet.
- Verify padding: the string length mod 4 must be 0 after padding.
- In tests, generate AWSByte values programmatically rather than hardcoding literal strings.
Example fix
// before
variables = Map.of("payload", "hello world");
// after
variables = Map.of("payload", Base64.getEncoder().encodeToString("hello world".getBytes())); Defensive patterns
Strategy: validation
Validate before calling
// Java: validate before sending the GraphQL request
private static final Base64.Decoder B64 = Base64.getDecoder();
static String requireValidAwsByte(String s) {
if (s == null) throw new IllegalArgumentException("AWSByte value is null");
try { B64.decode(s); } catch (IllegalArgumentException e) {
throw new IllegalArgumentException("Not valid base64: " + s, e);
}
return s;
} Type guard
static boolean isAwsByte(Object v) {
if (!(v instanceof String s) || s.isEmpty()) return false;
try { java.util.Base64.getDecoder().decode(s); return true; }
catch (IllegalArgumentException e) { return false; }
} Try / catch
catch (CoercingParseValueException e) {
// client-side: fix the encoding; do not retry the same payload
log.warn("AWSByte rejected: {}", e.getMessage());
payload = Base64.getEncoder().encodeToString(rawBytes);
} Prevention
- Always derive AWSByte values from byte[] via a standard base64 encoder, never hand-type them.
- Centralize encoding in one utility so URL-safe base64 cannot leak in.
- Property-test your client encoders round-trip with standard base64.
When it happens
Trigger: A GraphQL query or mutation supplies a variable or inline value for an AWSByte! / AWSByte field that contains characters outside the base64 alphabet (e.g. 'abc!!'), wrong padding ('QQ' instead of 'QQ=='), or plain text like 'hello'. Also triggered when a client sends URL-safe base64 ('-','_') where standard base64 ('+','/') is expected.
Common situations: Clients encrypting/encoding with URL-safe base64 by default (e.g. some JWT or crypto libraries), copying raw strings instead of base64 into AWSByte fields, or truncating base64 strings during manual testing. Mismatches after changing an encoding library version that alters padding behavior.
Related errors
AI-assisted analysis of floci-io/floci@62ff490619 (2026-08-14).
Data as JSON: /api/errors/35b714291d035eda.
Report an issue: GitHub.