anomalyco/sst · error · VisibleError
Invalid resolver ${operation}
Error message
Invalid resolver ${operation} What it means
`addResolver(operation)` expects a string of exactly two whitespace-separated tokens: the type name and the field, e.g. `"Query getUser"`. The parser splits the trimmed operation on whitespace; anything other than 2 parts (0, 1, or 3+ tokens) is rejected with a VisibleError showing the raw input.
Source
Thrown at platform/src/components/aws/app-sync.ts:821
* code: `
* export function request(ctx) {
* return {};
* }
* export function response(ctx) {
* return ctx.result;
* }
* `,
* });
* ```
*/
public addResolver(operation: string, args: AppSyncResolverArgs) {
const self = this;
const selfName = this.constructorName;
// Parse field and type
const parts = operation.trim().split(/\s+/);
if (parts.length !== 2)
throw new VisibleError(`Invalid resolver ${operation}`);
const [type, field] = parts;
const nameSuffix = `${logicalName(type)}` + `${logicalName(field)}`;
return new AppSyncResolver(
`${selfName}Resolver${nameSuffix}`,
{
apiId: self.api.id,
type,
field,
...args,
},
{ provider: this.constructorOpts.provider },
);
}
/** @internal */
public getSSTLink() {
return {View on GitHub (pinned to a0bd20f762)
Solutions
- Use space-separated syntax: `api.addResolver("Query.getUser", { ... })`
- Ensure exactly one space between type and field and no trailing tokens
- Verify the type name matches a type defined in your GraphQL schema (e.g. Query, Mutation, Subscription)
Example fix
// before
api.addResolver("Query.getUser", { ... });
// after
api.addResolver("Query getUser", { ... }); Defensive patterns
Strategy: validation
Validate before calling
function parseResolverOperation(op) {
const parts = op.trim().split(/\s+/);
if (parts.length !== 2) throw new Error(`addResolver expects "Type field" (space-separated), got: "${op}"`);
return { type: parts[0], field: parts[1] };
} Type guard
function isResolverOperation(op) {
return typeof op === "string" && op.trim().split(/\s+/).length === 2;
} Try / catch
null
Prevention
- Always use the space-separated "Type field" format, never "Type.field"
- Wrap addResolver calls in a helper that validates the two-token format
- Keep resolver registrations in one module so format mistakes are caught in one place
When it happens
Trigger: Calling `api.addResolver("Query.getUser")` (dot notation), `api.addResolver("Query")` (field omitted), or `api.addResolver("Mutation create Item extra")` — any string that does not split into exactly two tokens.
Common situations: Using GraphQL-style `Type.field` dot syntax instead of the space-separated form SST expects, or forgetting the field entirely when wiring a resolver.
Understand the failure class
Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.
Related errors
- Missing "name" for domain.
- Need to provide a validated certificate via "cert" when DNS
- Cannot configure "pauseAfter" when the minimum ACU is not 0
- Cannot create more than 15 read-only replicas for the "${nam
- Need to provide a validated certificate via "cert" when DNS
AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30).
Data as JSON: /api/errors/a9d86464c3413310.
Report an issue: GitHub.