hasura/graphql-engine · error

cannot read config: %w

Error message

cannot read config: %w

What it means

A filter predicate traverses a relationship whose source and target models live on different data connectors (different subgraphs). Cross-connector relationship filtering would require the engine to push a join across heterogeneous backends, which is not supported in filter expressions.

Source

Thrown at cli/cli.go:672

	// validate execution directory
	err := ec.validateDirectory()
	if err != nil {
		return errors.E(op, fmt.Errorf("validating current directory failed: %w", err))
	}

	// load .env file
	err = ec.loadEnvfile()
	if err != nil {
		return errors.E(op, fmt.Errorf("loading .env file failed: %w", err))
	}

	// set names of config file
	ec.ConfigFile = filepath.Join(ec.ExecutionDirectory, "config.yaml")

	// read config and parse the values into Config
	err = ec.readConfig()
	if err != nil {
		return errors.E(op, fmt.Errorf("cannot read config: %w", err))
	}

	// initialize HTTP client
	// CLI uses a common http client defined in internal/httpc.Client
	// get TLS Config
	tlsConfig, err := httpc.GenerateTLSConfig(ec.Config.CAPath, ec.Config.InsecureSkipTLSVerify)
	if err != nil || tlsConfig == nil {
		return errors.E(op, stderrors.New("error while getting TLS config"))
	}

	// create a net/http.Client with TLS Config
	standardHttpClient, err := httpc.NewHttpClientWithTLSConfig(tlsConfig)
	if err != nil || standardHttpClient == nil {
		return errors.E(
			op,
			fmt.Errorf("error while creating http client with TLS configuration %w", err),
		)
	}

View on GitHub (pinned to 724551b9ae)

Solutions

  1. Filter each subgraph's data separately and join at the client/graph level instead of inside the predicate
  2. Restructure so both sides of the relationship live on the same data connector
  3. Use a command or remote relationship that resolves cross-source data outside of filter predicates
  4. Drop the cross-connector relationship from the filter expression

Example fix

# before
where: { author: { name: { _eq: "A" } } } # author on different connector
# after
query { authors(where: { name: { _eq: "A" } }) { articles(where: {...}) } }
Defensive patterns

Strategy: validation

Validate before calling

// Reject cross-connector relationships in filter predicates up front
const src = model.connector[rel.source.model];
const tgt = model.connector[rel.target.model];
if (src !== tgt) throw new Error('Cross-subgraph relationship cannot be used in filters');

Type guard

const isSameSubgraph = (meta, sourceModel, targetModel) => meta.models[sourceModel].data_connector === meta.models[targetModel].data_connector;

Try / catch

try { resolveFilter(); } catch (e) { if (e?.code === 'RelationshipAcrossSubgraphs') splitQueryClientSide(); else throw e; }

Prevention

When it happens

Trigger: Using a relationship in a 'where' filter where source model uses connector A (e.g. Postgres) and target model uses connector B (e.g. DynamoDB); filtering across two subgraphs composed in a federated/multi-source metadata setup.

Common situations: Adding a second data connector and reusing existing relationships in filters; federation-style setups with remote relationships expected to behave like local joins.

Related errors


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