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

  1. Use space-separated syntax: `api.addResolver("Query.getUser", { ... })`
  2. Ensure exactly one space between type and field and no trailing tokens
  3. 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

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


AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30). Data as JSON: /api/errors/a9d86464c3413310. Report an issue: GitHub.