dgraph-io/dgraph · error

type %s in remote schema is not an INPUT_OBJECT.

Error message

type %s in remote schema is not an INPUT_OBJECT.

What it means

When validating the BATCH-mode argument, the argument's named type is looked up in the remote introspected types and its kind is checked. If the type exists but is not of kind INPUT_OBJECT (e.g. it is an OBJECT, SCALAR, or ENUM), this error states that the type is not an INPUT_OBJECT.

Source

Thrown at graphql/schema/remote.go:326

					Kind == inputObject) ||
				(inputTyp.Kind == nonNull && inputTyp.OfType != nil && inputTyp.OfType.
					Kind == list && inputTyp.OfType.OfType != nil && inputTyp.OfType.OfType.
					Kind == inputObject) ||
				(inputTyp.Kind == nonNull && inputTyp.OfType != nil && inputTyp.OfType.
					Kind == list && inputTyp.OfType.OfType != nil && inputTyp.OfType.OfType.
					Kind == nonNull && inputTyp.OfType.OfType.OfType != nil && inputTyp.
					OfType.OfType.OfType.Kind == inputObject)) {
				return errors.Errorf("argument `%s` for given %s `%s` must be of the form `[{param1"+
					": $var1, param2: $var2, ...}]` for BATCH mode in remote %s.", argName,
					operationType, givenQuery.Name, operationType)
			}
			inputTypName := inputTyp.NamedType()
			typ, ok := remoteTypes[inputTypName]
			if !ok {
				return missingRemoteTypeError(inputTypName)
			}
			if typ.Kind != inputObject {
				return errors.Errorf("type %s in remote schema is not an INPUT_OBJECT.", inputTypName)
			}
		}
	}

	if !metadata.isBatch {
		// check whether args of given query/mutation match the args of remote query/mutation
		err = matchArgSignature(&argMatchingMetadata{
			givenArgVals:  givenQryArgVals,
			givenVarTypes: givenQryVarTypes,
			remoteArgMd:   remoteQryArgMetadata,
			remoteTypes:   remoteTypes,
			givenQryName:  &givenQuery.Name,
			operationType: &operationType,
			schema:        metadata.schema,
		})
	}

	return err

View on GitHub (pinned to 759e242be6)

Solutions

  1. Declare the argument type in the remote schema with `input` keyword so its kind is INPUT_OBJECT.
  2. If a regular type with the same name exists, rename one of them so the argument resolves to the input type.
  3. Re-introspect the remote schema to confirm the kind after any upstream refactor.

Example fix

// before (remote)
type UserInput { id: ID!, name: String! }
// after
input UserInput { id: ID!, name: String! }
Defensive patterns

Strategy: type-guard

Validate before calling

const t = typesByName[arg.type.nameFetch()]
if (t && t.kind !== 'INPUT_OBJECT') throw new Error(`type ${t.name} must be declared with the 'input' keyword`)

Type guard

function isInputObject(type) { return type?.kind === 'INPUT_OBJECT' }

Prevention

When it happens

Trigger: validateRemoteGraphql finds typ in remoteTypes for the batch argument's NamedType but typ.Kind != inputObject (graphql/schema/remote.go:326) — e.g. argument declared as a list of an output object type.

Common situations: Remote API reuses an output type as the batch argument type; the remote schema changed an input type into a regular type; typo causes resolution to a same-named non-input type.

Related errors


AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/86c73e7c9abcda8b. Report an issue: GitHub.