From 1b92f83dc41d7e85381b6ae3744de1f27756318f Mon Sep 17 00:00:00 2001 From: Ryan Malloy Date: Sat, 9 May 2026 05:09:20 -0600 Subject: [PATCH] route_plan: fix Python-comment-in-f-string regression in translation_chain MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Live re-run after the c995bc2 Device-DN fix returned "A syntax error has occurred" from Informix. Cause: the explanatory comment block documenting why tkpatternusage=2 was added landed *inside* the translation_chain f-string instead of above it. Python's `#` line comments only work outside string literals — inside an f-string, each `#` is literal text. Informix received SQL with `#` lines after the JOIN clauses, parsed them as illegal tokens, and rejected. Offline tests didn't catch this because the FakeAxlClient dispatches on substring matches without actually parsing the SQL. The bug only manifested when the SQL hit a real Informix engine. Fix: move the comment block ABOVE the `sql = f"""` assignment so it becomes a real Python comment instead of literal SQL text. Sentinel test added (test_no_python_comment_chars_leak_into_sql): captures all SQL emitted by a cti_failsafe_reachability call and asserts no `#` character appears anywhere. CUCM's data dictionary doesn't use `#` in any table or column name, and Informix uses `--` / `/* */` for comments — so a `#` in any captured query is almost certainly an escaped Python comment. Catches this exact class of regression for any future contributor. Tests: cti suite 33 → 34; full mcaxl suite 271 → 272 passing. Operational impact: this regression made cti_failsafe_reachability unrunnable against any live cluster between c995bc2 and this fix. The Bingham 6→4 finding-reduction verification queued in 008 is unblocked once the MCP server reloads with this commit. --- src/mcaxl/route_plan.py | 33 +++++++++++++------------ tests/test_cti_failsafe_reachability.py | 33 +++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 16 deletions(-) diff --git a/src/mcaxl/route_plan.py b/src/mcaxl/route_plan.py index e11f6d3..ab284b9 100644 --- a/src/mcaxl/route_plan.py +++ b/src/mcaxl/route_plan.py @@ -1734,22 +1734,7 @@ def translation_chain(client: "AxlClient", number: str, css_name: str | None = N """ # Pull every pattern in scope; we filter in Python with wildcard logic. - sql = f""" - SELECT - np.dnorpattern AS pattern, - tpu.name AS pattern_type, - rp.name AS partition_name, - np.callingpartytransformationmask AS calling_party_xform_mask, - np.calledpartytransformationmask AS called_party_xform_mask, - np.prefixdigitsout AS prefix_digits_out, - ddi.name AS digit_discard_instructions, - rf.name AS route_filter, - np.description AS description - FROM numplan np - LEFT OUTER JOIN routepartition rp ON np.fkroutepartition = rp.pkid - LEFT OUTER JOIN typepatternusage tpu ON np.tkpatternusage = tpu.enum - LEFT OUTER JOIN digitdiscardinstruction ddi ON np.fkdigitdiscardinstruction = ddi.pkid - LEFT OUTER JOIN routefilter rf ON np.fkroutefilter = rf.pkid + # # tkpatternusage candidates included in the match scan: # 2 = Device (DN) — directly-dialable directory numbers # 3 = Translation — translation patterns @@ -1766,6 +1751,22 @@ def translation_chain(client: "AxlClient", number: str, css_name: str | None = N # was the cause of the false-positive: candidates_evaluated stayed # 23 vs 26 numplan rows in the reachable partition, with the 3-row # gap being exactly the 3 Device DNs. + sql = f""" + SELECT + np.dnorpattern AS pattern, + tpu.name AS pattern_type, + rp.name AS partition_name, + np.callingpartytransformationmask AS calling_party_xform_mask, + np.calledpartytransformationmask AS called_party_xform_mask, + np.prefixdigitsout AS prefix_digits_out, + ddi.name AS digit_discard_instructions, + rf.name AS route_filter, + np.description AS description + FROM numplan np + LEFT OUTER JOIN routepartition rp ON np.fkroutepartition = rp.pkid + LEFT OUTER JOIN typepatternusage tpu ON np.tkpatternusage = tpu.enum + LEFT OUTER JOIN digitdiscardinstruction ddi ON np.fkdigitdiscardinstruction = ddi.pkid + LEFT OUTER JOIN routefilter rf ON np.fkroutefilter = rf.pkid WHERE np.tkpatternusage IN (2, 3, 5, 7) AND np.dnorpattern IS NOT NULL {css_filter} diff --git a/tests/test_cti_failsafe_reachability.py b/tests/test_cti_failsafe_reachability.py index f51eced..27a2636 100644 --- a/tests/test_cti_failsafe_reachability.py +++ b/tests/test_cti_failsafe_reachability.py @@ -466,6 +466,39 @@ class TestDeviceDnInTranslationChainCandidates: "empirical proof." ) + def test_no_python_comment_chars_leak_into_sql(self): + """Sentinel — a `#` in any captured query is almost certainly a + Python comment that escaped its f-string. Informix doesn't use + `#` for comments (it uses `--` and `/* */`); CUCM's data + dictionary doesn't use `#` in table or column names either. + + Caught a real regression in 2026-05-09 cti-audit-prompts + thread: a Python explanatory comment was placed *inside* the + translation_chain f-string (after the JOIN clauses, before + WHERE). Informix returned "A syntax error has occurred" on + every live call. Offline tests passed because the FakeAxlClient + dispatched on substring matches and didn't parse the SQL. + + This test wouldn't have caught the original bug if it predated + the fix (the FakeAxlClient still wouldn't fail) — but adding + it now means a future contributor can't reintroduce the same + class of mistake in any cti_failsafe_reachability call path. + """ + client = FakeAxlClient(cti_rp_rows=[ + _cti_row("Test-RP", "Generic", cfna="912", cfna_css="SomeCSS"), + ]) + cti_failsafe_reachability(client) + for q in client.queries: + # Allow `#` in column-comment-like positions in SELECT lists? + # No — CUCM's data dictionary has no such columns. A `#` + # anywhere in any query my tool emits is a defect. + assert "#" not in q, ( + f"Python `#` character leaked into SQL — likely a Python " + f"comment inside an f-string. Informix will reject this " + f"with 'A syntax error has occurred'. Offending query:\n" + f"{q[:200]}..." + ) + def test_cti_rp_to_cti_rp_failsafe_does_not_false_positive(self): """The motivating Bingham case: 911-CTI-RP CFNA → 912 (Device DN of 912-CTI-RP) under 911CER-CSS reaching 911CER-PT.