[dbt-bigquery] Custom api_endpoint causes literal "https" hostname resolution failure ("Reopening connection" loop) #2103

Describe the bug

Jobs on an account with a custom BigQuery api_endpoint configured are failing continuously with the adapter attempting to resolve the literal string https as a DNS hostname, rather than the actual configured endpoint host. This breaks every affected run and the adapter enters a retry loop without recovering.

Error signature

BigQuery adapter: Reopening connection after ConnectionError(MaxRetryError('HTTPSConnectionPool(host=\'https\', port=443): Max retries exceeded with url: //<custom-endpoint-host>/bigquery/v2/projects/<project>/datasets?maxResults=10000&prettyPrint=false (Caused by NameResolutionError("HTTPSConnection(host=\'https\', port=443): Failed to resolve \'https\' ([Errno -2] Name or service not known)"))'))

and

Encountered an error:
Database Error
  HTTPSConnectionPool(host='https', port=443): Max retries exceeded with url: //<custom-endpoint-host>/bigquery/v2/projects/<project>/datasets?maxResults=10000&prettyPrint=false (Caused by NameResolutionError("HTTPSConnection(host='https', port=443): Failed to resolve 'https' ([Errno -2] Name or service not known)"))

Note the request line: url: //<custom-endpoint-host>/bigquery/v2/projects/... — the scheme (https:) has been separated from the host during URL construction, so the HTTP client ends up trying to open a connection to a host literally named https on port 443, instead of the configured endpoint host.

Steps to reproduce / observed context

• A dbt Cloud account has a custom BigQuery api_endpoint configured pointing at a third-party proxy in front of BigQuery (e.g. https://<proxy-host>).
• The stored api_endpoint value was visually confirmed (via screenshot in support tooling) to be a single, correctly-formed URL — no duplicated scheme, no stray https: line.
• Despite the stored config being clean, the error recurred continuously in production logs, roughly every 5 minutes, over a multi-hour window.
• Confirmed root cause / repro: removing the https:// scheme prefix from the configured api_endpoint field — leaving just the bare host (e.g. <proxy-host> instead of https://<proxy-host>) — resolved the issue entirely; jobs ran clean afterward. This confirms the adapter is unconditionally prepending its own https:// scheme at request-construction time, without checking whether the configured value already includes a scheme. When the configured value already has https://, the resulting URL construction/parsing drops the real host and leaves https as the literal hostname.
• Reported via an internal dbt Labs support ticket; happy to share account/connection details privately with a maintainer if needed for reproduction, rather than posting them publicly here.

Expected behavior

When a custom api_endpoint is configured, the adapter should construct request URLs using the full scheme+host as configured, without splitting or dropping the scheme, regardless of whether the user's input already includes a scheme. Suggested fix direction: check for an existing http:///https:// prefix before prepending one (or normalize by stripping any existing scheme first, then prepending consistently), so both scheme-included and bare-host input work correctly.

Is this related to the known Fusion issue dbt-core#14617?

No — confirmed this is not a duplicate of dbt-labs/dbt-core#14617. That issue is Fusion-only (engine:v2), affects the Storage Read API gRPC path, and produces a distinct error ("[BigQuery] Storage API is not available for query"). This issue's error comes from the classic Python BigQuery adapter: Reopening connection... code path (dbt Core v1 style adapter, in dbt-bigquery), and Fusion is not involved in the affected jobs' execution path for the account in question.