Stale pooled Snowflake connection causes "terminated connection" errors in sql_execute/sql_explain/schema_inspect/warehouse_test while altimate-dbt stays functional #1411

The error is coming from the MCP tool layer's connection pool, not from Snowflake itself or from altimate-dbt.

Evidence:

• warehouse_test and schema_inspect both failed with the identical message: ClientError: Unable to perform operation using terminated connection. — for both jaffle_shop_core_dev and jaffle_shop_dev (same Snowflake account EJJKBKO-FUB20041, same key file, same warehouse sa_wh).
• Meanwhile, every single altimate-dbt execute call against the exact same account/database/schema succeeded throughout the session (row counts, status breakdown, PK checks, orphan checks — all returned data).

That split tells us the credentials, key file, network path, and Snowflake account are all fine. If they weren't, altimate-dbt would have failed too, since it's hitting the same warehouse. So this isn't a real connectivity/auth problem.

What's actually going on: sql_execute, sql_explain, schema_inspect, and warehouse_test share a cached Snowflake connection object maintained by the tool dispatcher process for this session. At some point that cached connection was closed server-side (Snowflake idle-connection timeout, a network blip, or the sa_wh warehouse auto-suspending/resuming in a way that invalidated the session token) — but the dispatcher kept trying to reuse the now-dead connection object instead of detecting the drop and reconnecting. Every subsequent call through that pooled connection fails immediately with "terminated connection," because the client-side socket object is stale, not because the server rejected a new login.

altimate-dbt, by contrast, opens a fresh dbt adapter connection on every invocation (visible in the logs — "Registered adapter: snowflake=1.11.1" printed on every single call), so it never hit the stale pooled handle and kept working fine.

Impact: a usable warehouse connection was available via altimate-dbt execute the whole time (used to get row counts, PK uniqueness, and fan-out numbers), but sql_explain could not produce an execution plan since it depends on the pooled connection path.

Suggested fix: the dispatcher's connection pool should detect a dead/terminated connection and transparently reconnect (or at least surface a clearer "connection pool stale, retrying" error) instead of repeatedly failing every call through the dead handle for the rest of the session. Workarounds observed: this clears on its own at the start of a new session (new dispatcher process = fresh connection pool), or can be forced by warehouse_remove + warehouse_add to recreate the connection object.

Metadata