ADBC FlightSQL "name resolver error: produced zero addresses" inside query_metrics, but standalone adbc_connect() to same host succeeds

[CloudChaoszero]

Summary

Calling query_metrics via dbt-mcp fails with an ADBC FlightSQL DNS/name-resolution error, but a hand-rolled adbc_connect() call using the exact same driver, host, and credentials succeeds standalone. The failure appears to be scoped specifically to how the ADBC client is constructed/managed inside dbt-mcp's / dbt-sl-sdk's query_metrics code path, not to networking, auth, or config.

Environment

• dbt-mcp==2.0.0b1 (beta)
• dbt-sl-sdk==0.13.3
• adbc-driver-flightsql==1.12.0

Error

IO: [FlightSQL] name resolver error: produced zero addresses (Unavailable; Prepare). Vendor code: 14

What's been ruled out

Every layer that can be tested independently works correctly:

• GraphQL auth
• Credentials
• Environment ID
• Driver versions
• TLS
• DNS resolver settings
• GUI vs. shell environment differences

Reproduction detail

A hand-rolled connection using adbc_connect() with the same FlightSQL driver, same host, and same auth succeeds and returns data. The only difference is going through dbt-mcp's actual query_metrics call path (which delegates to dbt-sl-sdk's ADBC client), which fails with the name-resolution error above on Prepare.

This points to a bug in how dbt-mcp 2.0.0b1 or dbt-sl-sdk 0.13.3 constructs or manages the ADBC client internally (e.g. a host/URL not being passed through correctly to the underlying FlightSQL client, or a client being reused/constructed in a way that loses the resolved address) rather than anything fixable via local config.

Suggested next step

Reading through dbt-sl-sdk's query_metrics implementation (or dbt-mcp's wrapper around it) to see how the ADBC client/channel is constructed, versus the working hand-rolled adbc_connect() call, should narrow down where the address gets dropped.