fix: [AI-9011] bump sqlglot[c] pin to 30.11.0 for the resolver recursion fix

[Sourabhchrs93]

Bumps the sqlglot[c] pin from 30.7.0 to 30.11.0 to pick up an upstream fix for unbounded recursion in the optimizer's column Resolver.

Why

sqlglot 30.7.0 — the version we pin today — carries a regression (upstream #7732) where qualifying a LATERAL FLATTEN of an unqualified column whose base table is absent from the supplied schema recurses forever:

get_source_columns → _get_unnest_column_type → get_table
  → _get_table_name_from_sources → _get_all_source_columns → get_source_columns → ∞

Each pass constructs a fresh Resolver, so the per-instance caches never break the cycle and there is no visited guard.

On a pure-Python build this raises a catchable RecursionError. On the compiled build we pin here, the recursion runs in mypyc-native frames that don't honour Python's recursion limit — so it overflows the C stack into an uncatchable SIGSEGV. No try/except can recover it; the process simply dies.

Impact

In altimate-backend, the dbt column-lineage subprocess runs this exact path. Six sunrun models hit the trigger and segfaulted the worker nightly, which then wedged the Celery task and cost the dbt worker one of its five pool slots every night since 2026-07-31 (AI-9011).

The fix

Upstream PR #7737 fixed it; first release containing it is 30.11.0.

Keeping the [c] extra. Dropping it would also stop the crash (a RecursionError is catchable), but the compiled build is ~2.7x faster on optimize (1.8 ms vs 4.9 ms/call measured on real dbt SQL) and the speedup it was added for in #101 still applies. This bump gets the fix without giving that up.

Verification

• All six previously-crashing models: rc=139 (SIGSEGV) on 30.7.0 → no crash on 30.11.0. Four now optimize cleanly; two raise a normal catchable OptimizeError from validate_qualify_columns, which is the documented behaviour for partial schemas.
• Full suite on 30.11.0: 157 passed.
• SqlCheck inspects optimizer rules via inspect.getfullargspec(rule).args, which chore: bump sqlglot pin to sqlglot[c]==30.7.0 #101 called out as the compat risk — still fine on 30.11.0, covered by the passing suite.

Chose 30.11.0 rather than latest (30.18.0) as the minimal delta containing the fix; 30.18.0 was also verified clean if we'd rather jump further.

Note for whoever picks this up: altimate-dags pins sqlglot too and #101 deliberately aligned all consumers on one version — worth bumping it in step. altimate-backend can only move off 30.7.0 once this is released, since the pin here is exact.

🤖 Generated with Claude Code

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 files)

• setup.py

---

_{Reviewed by gpt-sol-latest · Input: 0 · Output: 0 · Cached: 0}