dgraph-io/dgraph · error

%s: %s

Error message

%s: %s

What it means

resolveListBackups wraps any failure from worker.ProcessListBackups (the underlying backup listing call) into a uniform '<x.Error>: <detail>' message and returns an empty GraphQL result. The prefix comes from the shared x.Error constant, and the suffix is the raw error from the backup-locating backend (S3, Minio, filesystem, Azure, GCS). It signals the backup listing itself failed — not a date-filter or conversion problem.

Source

Thrown at graphql/admin/list_backups.go:138

	if err != nil {
		return resolve.EmptyResult(q, err)
	}

	filter, err := buildBackupDateFilter(input)
	if err != nil {
		return resolve.EmptyResult(q, err)
	}

	creds := &x.MinioCredentials{
		AccessKey:    input.AccessKey,
		SecretKey:    input.SecretKey,
		SessionToken: input.SessionToken,
		Anonymous:    input.Anonymous,
	}
	manifests, err := worker.ProcessListBackups(ctx, input.Location, creds,
		needsFullManifest(input.FullManifest, q.SelectionSet()))
	if err != nil {
		return resolve.EmptyResult(q, errors.Errorf("%s: %s", x.Error, err.Error()))
	}
	manifests = worker.FilterManifestsByDate(manifests, filter)

	convertedManifests := convertManifests(manifests)

	results := make([]map[string]interface{}, 0)
	for _, m := range convertedManifests {
		b, err := json.Marshal(m)
		if err != nil {
			return resolve.EmptyResult(q, err)
		}
		var result map[string]interface{}
		err = schema.Unmarshal(b, &result)
		if err != nil {
			return resolve.EmptyResult(q, err)
		}
		results = append(results, result)
	}

View on GitHub (pinned to 759e242be6)

Solutions

  1. Read the suffix after the colon: it names the real backend error (e.g. AccessDenied, NoSuchBucket) and fix that underlying issue first.
  2. Verify the location URI and that the bucket/container actually exists and is reachable from the Dgraph Alpha.
  3. Check credentials: access keys, session token, anonymous flag, or instance IAM role; test with aws s3 ls or equivalent from the same host.
  4. Confirm network/DNS/firewall access from the Alpha node to the object storage endpoint.
  5. Retry the GraphQL operation once the backend issue is fixed; nothing in the GraphQL layer itself needs changing.

Example fix

// before: wrong location
{ listBackups(input: { location: "s3://my-backups/", accessKey: "AKIA...", secretKey: "..." }) }
// after: verified bucket + valid creds
{ listBackups(input: { location: "s3://my-backups/dgraph", accessKey: "AKIA...", secretKey: "...", region: "us-east-1" }) }
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: verify location and creds from the client before listing
const loc = 's3://my-bucket/dgraph';
if (!/^([a-z0-9]+:\/\/.+)$/.test(loc)) throw new Error('unsupported backup location URI');
// ensure keys are set when not using instance IAM role
if (!accessKey || !secretKey) throw new Error('missing backup credentials');

Try / catch

try {
  const res = await gql(listBackupsQuery);
} catch (e) {
  const detail = e.message.split(': ').slice(1).join(': '); // backend error after x.Error prefix
  if (/AccessDenied|InvalidAccessKeyId/.test(detail)) rotateCredentialsAndRetry();
  else if (/NoSuchBucket|not found/.test(detail)) fixLocationAndRetry();
  else throw e;
}

Prevention

When it happens

Trigger: Running the admin listBackups GraphQL operation when the underlying worker cannot read the backup location: bad/missing S3 credentials or region, nonexistent bucket/path, network failure to object storage, or the location URI scheme is unsupported.

Common situations: Misconfigured access keys or IAM policy lacking s3:ListBucket, typos in the s3:// location string, unreachable Minio endpoint, or credentials passed via sessionToken/anonymous flags that the backend rejects. Also common after rotating cloud credentials without restarting Dgraph.

Related errors


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