dgraph-io/dgraph · error

cannot retrieve manifests

Error message

cannot retrieve manifests

What it means

RunMapper wraps any failure from getManifestsToRestore — the step that lists the backup location via the URI handler and parses the manifest files — with 'cannot retrieve manifests'. The underlying error (network, credentials, missing/invalid manifest) is preserved by errors.Wrapf.

Source

Thrown at worker/restore_map.go:755

// value in having these partition keys. Maybe, we can live without them.
func RunMapper(req *pb.RestoreRequest, mapDir string) (*mapResult, error) {
	uri, err := url.Parse(req.Location)
	if err != nil {
		return nil, err
	}
	if req.RestoreTs == 0 {
		return nil, errors.New("RestoreRequest must have a valid restoreTs")
	}

	creds := getCredentialsFromRestoreRequest(req)
	h, err := NewUriHandler(uri, creds)
	if err != nil {
		return nil, err
	}

	manifests, err := getManifestsToRestore(h, uri, req)
	if err != nil {
		return nil, errors.Wrapf(err, "cannot retrieve manifests")
	}
	glog.Infof("Got %d backups to restore ", len(manifests))

	cfg, err := getEncConfig(req)
	if err != nil {
		return nil, errors.Wrapf(err, "unable to get encryption config")
	}
	keys, err := x.GetEncAclKeys(cfg)
	if err != nil {
		return nil, errors.Wrapf(err, "unable to get encryption keys")
	}

	mapper := &mapper{
		buf:       z.NewBuffer(mapFileSz, "Restore.Buffer"),
		thr:       y.NewThrottle(3),
		bufLock:   &sync.Mutex{},
		closer:    z.NewCloser(1),
		reqCh:     make(chan listReq, 3),

View on GitHub (pinned to 759e242be6)

Solutions

  1. Read the wrapped cause in the error chain to see the actual storage/parse failure.
  2. Verify req.Location scheme, bucket and prefix, and that credentials (via getCredentialsFromRestoreRequest) are valid for that store.
  3. Confirm the location actually contains a valid backup: run `dgraph backup -l` equivalent listing or inspect the manifest objects directly.
  4. If restoring to a point in time, ensure a full backup exists at or before the requested SinceTs/RestoreTs.
  5. Test connectivity from the host (e.g. aws s3 ls / gsutil ls on the same path) to rule out network/permissions.

Example fix

// before
req := &pb.RestoreRequest{Location: "s3://wrong-bucket/backups"}
// after
req := &pb.RestoreRequest{Location: "s3://correct-bucket/dgraph-backups", AccessKey: ak, SecretKey: sk, RestoreTs: ts}
Defensive patterns

Strategy: try-catch

Validate before calling

// pre-flight: verify the location is listable with the same creds
err := probeBackupLocation(req.Location, creds) // aws s3 ls / gsutil equivalent
if err != nil { return fmt.Errorf("backup location unreachable: %w", err) }

Try / catch

if _, err := worker.RunMapper(req, mapDir); err != nil {
    if strings.Contains(err.Error(), "cannot retrieve manifests") {
        // inspect errors.Cause(err) for storage/credential issue
        return fmt.Errorf("check location, credentials and manifest presence: %w", err)
    }
    return err
}

Prevention

When it happens

Trigger: getManifestsToRestore fails because the object store is unreachable, credentials are wrong, the location prefix contains no valid backup manifest, or a manifest file is corrupt/mismatched with the requested BackupId/restore-to timestamp.

Common situations: Wrong URI/scheme in req.Location (s3://, minio://, file://) or bad bucket/path; expired or missing AWS/GCS/Azure credentials; restoring from a location where no full backup exists at or before RestoreTs; firewall blocking egress to the storage endpoint.

Related errors


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