You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 8bb695e
Browse filesBrowse the repository at this point in the historyBrowse files
fix(guards): stop TokenError escaping the SQL guard as pipeline_exception
sqlglot's failure modes are siblings under SqlglotError, not a chain: the
parser raises ParseError, the lexer raises TokenError. `_safe_parse` caught
only ParseError, so an unterminated string literal escaped validate_sql,
crashed the pipeline node and was recorded as `pipeline_exception` — a model
failure wearing a transport failure's label, on a project whose runs are
judged clean by exactly that counter.
Observed live: q1399 of the 2026-07-22 student-base run
("Error tokenizing '...T1.last_name = 'Mclean'", pred_sql lost, in_tok 0).
Three consequences, not one: the run's health signal lied; the offending SQL
was dropped from the record; and the question never reached repair_once,
because a raised exception skips routing that invalid_sql would have taken.
Probing the parser for other escapes found a second one: RecursionError on
deeply nested parens, which is not a SqlglotError at all. Both now come back
as violations — the guard's documented contract is to report, never raise.
The same narrow `except ParseError` sat on three more parse sites whose own
docstrings promise a fallback instead of a crash (eval/dataset.extract_gold_
tables, autotune/build_dataset.{extract_tables,sql_parses}, p3f_acceptance).
Corrected there too; measured unreachable on current data (370 distinct gold
SQLs, 9428 bird_train rows all parse), so S1's "parse-fail 0" is unchanged.
Gate §7.3 green: ruff, format 190, mypy 108, pytest 555 passed / 14 skipped
cov 91.05%, hygiene 542, no_raw_compare.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments