dgraph-io/dgraph · error

map phase failed to parse namespace

Error message

map phase failed to parse namespace

What it means

During the map phase, DropOperations with DropOp_NS carry the namespace id as a string in op.DropValue. RunMapper parses it with strconv.ParseUint and wraps any parse failure as 'map phase failed to parse namespace', since a non-numeric DropValue would silently corrupt namespace-drop handling.

Source

Thrown at worker/restore_map.go:873

				return nil, errors.Wrap(err, "mapper.Map")
			}
			if err := br.Close(); err != nil {
				return nil, errors.Wrap(err, "br.Close")
			}
		}
		for _, op := range manifest.DropOperations {
			switch op.DropOp {
			case pb.DropOperation_ALL:
				dropAll = true
			case pb.DropOperation_DATA:
				if op.DropValue == "" {
					// In 2103, we do not support namespace level drop data.
					dropAll = true
					continue
				}
				ns, err := strconv.ParseUint(op.DropValue, 0, 64)
				if err != nil {
					return nil, errors.Wrap(err, "map phase failed to parse namespace")
				}
				dropNs[ns] = struct{}{}
			case pb.DropOperation_ATTR:
				dropAttr[op.DropValue] = struct{}{}
			case pb.DropOperation_NS:
				// pstore will be nil for export_backup tool. In that case we don't need to ban ns.
				if pstore == nil {
					continue
				}
				// If there is a drop namespace, we just ban the namespace in the pstore.
				ns, err := strconv.ParseUint(op.DropValue, 0, 64)
				if err != nil {
					return nil, errors.Wrapf(err, "Map phase failed to parse namespace")
				}
				if err := pstore.BanNamespace(ns); err != nil {
					return nil, errors.Wrapf(err, "Map phase failed to ban namespace: %d", ns)
				}
				maxBannedNs = x.Max(maxBannedNs, ns)

View on GitHub (pinned to 759e242be6)

Solutions

  1. Inspect the manifest's DropOperations and confirm DropValue for NS entries is a numeric string (e.g. "2").
  2. Restore with a Dgraph version matching the one that produced the backup — the drop-op encoding may differ across versions.
  3. Fix or regenerate the manifest if it was hand-edited or written by third-party tooling.
  4. If the drop op is unimportant, remove that DropOperations entry from a corrected copy of the manifest (advanced, at own risk).

Example fix

// manifest DropOperations before (corrupt)
{"DropOp":"NS","DropValue":""}
// after
{"DropOp":"NS","DropValue":"2"}
Defensive patterns

Strategy: validation

Validate before calling

// validate manifests before restore
for _, op := range manifest.DropOperations {
    if op.DropOp == pb.DropOperation_NS {
        if _, err := strconv.ParseUint(op.DropValue, 0, 64); err != nil {
            return fmt.Errorf("manifest has invalid NS DropValue %q", op.DropValue)
        }
    }
}

Prevention

When it happens

Trigger: A manifest's DropOperations entry of type DropOp_NS has DropValue that is not a valid base-0 uint64 (empty, alphabetic, malformed) while processing manifest drop operations in RunMapper.

Common situations: Backups produced by versions that encoded namespace drops differently (format mismatch between writer and restorer); hand-edited or corrupted manifest JSON; a bug in the tooling that generated the manifest.

Understand the failure class

Related errors


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