encountered an XID %s with %s that isn't a Int64 but data ty

Error message

encountered an XID %s with %s that isn't a Int64 but data type in schema is Int64

What it means

While extracting an @id (XID) value declared as Int64 in the schema, Dgraph received a runtime type other than json.Number (int) or string. Int64 XIDs intentionally accept both numeric and string forms, but anything else (float, object, bool) fails with this error naming the XID field and schema type.

Source

Thrown at graphql/resolve/mutation_rewriter.go:2472

		default:
			return "", fmt.Errorf("encountered an XID %s with %s that isn't "+
				"a Int but data type in schema is Int", xidName, typeName)
		}
	case "Int64":
		switch xVal := xidVal.(type) {
		case json.Number:
			val, err := xVal.Int64()
			if err != nil {
				return "", err
			}
			return strconv.FormatInt(val, 10), nil
		case int64:
			return strconv.FormatInt(xVal, 10), nil
		// If the xid field is of type Int64, both String and Int forms are allowed.
		case string:
			return xVal, nil
		default:
			return "", fmt.Errorf("encountered an XID %s with %s that isn't "+
				"a Int64 but data type in schema is Int64", xidName, typeName)
		}
		// "ID" is given as input for the @extended type mutation.
	case "String", "ID":
		xidString, ok := xidVal.(string)
		if !ok {
			return "", fmt.Errorf("encountered an XID %s with %s that isn't "+
				"a String", xidName, typeName)
		}
		return xidString, nil
	default:
		return "", fmt.Errorf("encountered an XID %s with %s that isn't"+
			"allowed as Xid", xidName, typeName)
	}
}

// This function will return interface type and variable for existence query on interface,
// if given xid is inherited from interface, otherwise it will return nil and empty string

View on GitHub (pinned to 759e242be6)

Solutions

Send the value as a plain integer (12345) or a numeric string ("12345") — both are valid for Int64 XIDs.
Remove fractional/decimal parts from the value before sending.
If values can be arbitrary, declare the XID as String in the schema.
Inspect the raw JSON body of the request to confirm the variable's actual type.

Example fix

// before (variables)
{ "xid": 123.45 }
// after
{ "xid": "12345" } // or 12345

Defensive patterns

Strategy: type-guard

Validate before calling

function assertInt64Xid(v, field) {
  const ok = typeof v === 'string' || (typeof v === 'number' && Number.isInteger(v));
  if (!ok) throw new Error(`${field} must be an integer or numeric string for @id(Int64)`);
  return v;
}

Type guard

function isInt64Compatible(v) {
  return typeof v === 'string' || (typeof v === 'number' && Number.isInteger(v));
}

Try / catch

try {
  await client.mutate({ mutation: ADD, variables: { input } });
} catch (e) {
  if (/isn't a Int64 but data type in schema is Int64/.test(e.message)) {
    // send as integer or numeric string, then retry
  } else throw e;
}

Prevention

Send Int64 XIDs as integers or strings only — never floats or booleans.
Round or reject fractional values client-side before mutation.
Validate variable types against the GraphQL operation signature.
Recheck client serializers after migrating a field to Int64.

When it happens

Trigger: An add/update mutation supplying a value for an @id field of schema type Int64 whose JSON value is neither an integer nor a string — e.g. a float like 1.5, a boolean, or a nested object.

Common situations: Clients sending floats with fractional parts, frameworks serializing IDs as objects or arrays by mistake, or a schema migration changing the field to Int64 while clients still send exotic types.

Related errors

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