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 errView on GitHub (pinned to 759e242be6)
Solutions
- Declare the argument type in the remote schema with `input` keyword so its kind is INPUT_OBJECT.
- If a regular type with the same name exists, rename one of them so the argument resolves to the input type.
- 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
- Always declare batch argument types with `input`, never `type`
- Avoid name collisions between input and output types
- Assert INPUT_OBJECT kind in remote schema tests
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
- POST method cannot have query parameters in url: %s
- while json unmarshaling result from remote introspection que
- remote schema doesn't have any queries.
- remote schema doesn't have any mutations.
- %s `%s` is not present in remote schema.
AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01).
Data as JSON: /api/errors/86c73e7c9abcda8b.
Report an issue: GitHub.