hasura/graphql-engine · error

applying data sources failed: %s

Error message

applying data sources failed: %s

What it means

Returned by the metadata apply flow when applying data sources to the Hasura server fails. The message embeds the raw response body from the Hasura API (string(b)), so the actual server-side error (path/configuration invalid, connection to source DB failed, etc.) is included verbatim. It is tagged with errors.KindHasuraAPI, identifying it as a server API failure rather than a client-side one.

Source

Thrown at cli/commands/metadata_apply_data_sources.go:145

	}

	resp, body, err := o.EC.APIClient.V1Metadata.SendCommonMetadataOperation(
		json.RawMessage(requestBody),
	)
	if err != nil {
		return errors.E(op, err)
	}

	if resp.StatusCode != http.StatusOK {
		b, err := io.ReadAll(body)
		if err != nil {
			return errors.E(op, errors.KindHasuraAPI, err)
		}

		return errors.E(
			op,
			errors.KindHasuraAPI,
			fmt.Errorf("applying data sources failed: %s", string(b)),
		)
	}

	o.EC.Logger.Infof("Data sources applied (%d)", numSources)

	return nil
}

// addSourceArgs holds only the fields accepted by the server's `<kind>_add_source` metadata API.
// Notably it excludes tables/functions/permissions so that this operation only touches the source's
// connection configuration and never the rest of the source's metadata.
type addSourceArgs struct {
	Name                 string    `yaml:"name"`
	Configuration        yaml.Node `yaml:"configuration"`
	ReplaceConfiguration bool      `yaml:"replace_configuration"`
	Customization        yaml.Node `yaml:"customization,omitempty"`
	HealthCheck          yaml.Node `yaml:"health_check,omitempty"`
}

View on GitHub (pinned to 724551b9ae)

Solutions

1. Read the embedded response body in the error — it names the failing data source and the reason (e.g. 'connection refused', 'invalid connection string')
2. Test connectivity from the Hasura server to each database in data_sources before applying
3. Verify env-var interpolation in the metadata files is resolved in the environment where apply runs
4. Align CLI metadata format with the server version; re-export metadata from a server of the same version and re-apply your changes on top

Example fix

# before (data_sources.yaml with unreachable DB)
databases:
- name: default
  configuration:
    connection_info:
      database_url: postgres://db:5432/app
# after — point to a reachable instance or use env var
      database_url: ${DATABASE_URL}

# Shell: verify each data source DB is reachable before apply
for db in default pg2; do
  pg_isready -d "$db" || exit 1
done
hasura metadata apply

// Go: detect API-kind failures and dump the response body
kind := errors.Kind(err)
if kind == errors.KindHasuraAPI {
  log.Printf("server rejected data sources: %v", err)
  // fall back to applying sources one at a time to isolate the bad one
}

When it happens

Trigger: Running `hasura metadata apply` (or code invoking this Run) with a metadata data_sources.yaml/config that the server rejects: invalid database URL, unreachable database, unsupported driver, duplicate source name, or a source configuration the server version cannot parse. The Hasura /v1/metadata or data source API returns a non-success response whose body becomes the message.

Common situations: Environment variables for database URLs not set when applying, database behind a firewall unreachable from the server, applying metadata exported from a newer Hasura version to an older server, or mismatched source NENO/LINEAR config keys.

Related errors

• failed to clear metadata: %w
• failed to export metadata: %w
• pulling latest actions codegen files from internet failed: %
• unable to fetch introspection schema: %w
• error in fetching introspection schema: %w

AI-assisted analysis of hasura/graphql-engine@724551b9ae (2026-08-28). Data as JSON: /api/errors/6daae5a9d37a0913. Report an issue: GitHub.