dgraph-io/dgraph · error

Map phase failed to ban namespace: %d

Error message

Map phase failed to ban namespace: %d

What it means

During the map phase of a restore/export, when the backup manifest contains a drop-namespace operation, RunMapper tries to ban that namespace in the posting store via pstore.BanNamespace. This error wraps any failure from that call (e.g. the store rejected the ban) and includes the namespace ID being banned.

Source

Thrown at worker/restore_map.go:889

				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)
			}
		}
		glog.Infof("[MAP] Processed manifest num: %v", manifest.BackupNum)
	} // done with all the manifests.

	glog.Infof("Histogram of map input sizes:\n%s\n", mapper.szHist)
	close(mapper.reqCh)
	if err := g.Wait(); err != nil {
		return nil, errors.Wrapf(err, "from processKVList")
	}
	if err := mapper.Flush(); err != nil {
		return nil, errors.Wrap(err, "failed to flush the mapper")
	}
	mapRes := &mapResult{
		maxUid:        mapper.maxUid,
		maxNs:         mapper.maxNs,

View on GitHub (pinned to 759e242be6)

Solutions

  1. Inspect the wrapped root cause error (errors.Wrapf preserves it) and fix the underlying pstore failure
  2. Verify the posting store (Badger) directories are writable and healthy on this Alpha
  3. Retry the restore once the store is healthy; the ban is idempotent per namespace
  4. Check disk space and file permissions on the node running RunMapper

Example fix

// before
if err := pstore.BanNamespace(ns); err != nil {
    return nil, errors.Wrapf(err, "Map phase failed to ban namespace: %d", ns)
}
// after
if err := pstore.BanNamespace(ns); err != nil {
    glog.Errorf("ban namespace %d failed: %v; check pstore health", ns, err)
    return nil, errors.Wrapf(err, "Map phase failed to ban namespace: %d", ns)
}
Defensive patterns

Strategy: try-catch

Validate before calling

if err := validatePstoreWritable(); err != nil { return fmt.Errorf("pstore not writable before restore: %w", err) }

Try / catch

res, err := RunMapper(ctx, opts)
if err != nil {
    if strings.Contains(err.Error(), "failed to ban namespace") {
        // check pstore health/disk, then retry restore
        return retryRestore(opts)
    }
    return err
}

Prevention

When it happens

Trigger: RunMapper processes a manifest with DropValue set to a namespace ID; strconv.ParseUint succeeds but pstore.BanNamespace(ns) returns an error (internal posting-store failure writing the ban key).

Common situations: Offline restores or export-based backups where the underlying posting store is unhealthy, read-only, or the ban key write fails mid-restore; corruption or network issues to the Badger/pstore backend.

Related errors


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