cucx-docs's 007 empirically proved that route_translation_chain's
candidate filter `WHERE np.tkpatternusage IN (3, 5, 7)` excluded
Device DNs (tkpatternusage=2), which caused false-positive HIGH
findings on CTI-RP-to-CTI-RP failsafe chains — the typical CER
deployment shape.
The Bingham canary: 911-CTI-RP CFNA → 912 (DN of 912-CTI-RP) under
911CER-CSS. Direct numplan query against 911CER-PT returns 26 rows;
translation_chain reported `candidates_evaluated: 23`. The 3-row
gap is exactly the 3 Device DNs, excluded by the pre-fix filter
regardless of input number.
CUCM's runtime CFNA matcher includes Device DNs (otherwise no one
could dial 912 and reach the device). My tool's exclusion diverged
from production routing semantics. Result: every cluster using a
CTI-RP-to-CTI-RP failsafe pattern got at least one false-positive
HIGH finding on its first cti_failsafe_reachability run, wasting
operator investigation time on a phantom defect.
This commit broadens the candidate filter:
- WHERE np.tkpatternusage IN (3, 5, 7)
+ WHERE np.tkpatternusage IN (2, 3, 5, 7)
^
Device DN
Side effect: route_translation_chain now also surfaces Device DNs as
matches when called directly, which matches production routing
semantics. Existing callers benefit automatically.
The _note in the response now names the candidate set explicitly so
future readers don't have to dig into the SQL to know what's
included.
Updated comment block above the WHERE clause documents:
- which tkpatternusage values are included and why
- the empirical observation that motivated including Device DNs
- cross-reference to cti-audit-prompts/007 for the smoking-gun
candidates_evaluated:23-vs-26 evidence
Tests: +2 in TestDeviceDnInTranslationChainCandidates:
- test_translation_chain_sql_includes_device_dn_usage: lock the
SQL down so a future contributor can't re-narrow the filter to
(3, 5, 7) and re-introduce the false-positive class
- test_cti_rp_to_cti_rp_failsafe_does_not_false_positive: the
Bingham canary scenario — 911-CTI-RP forwarding to a Device DN
in a reachable partition correctly produces zero findings
The dispatch fake's SQL match-string updated from "(3, 5, 7)" to
"(2, 3, 5, 7)" to keep the existing 31 cti tests green; net
mcaxl suite: 269 → 271 passing.
Live re-run pending — will ping the agent thread with post-patch
output once the MCP server reloads.
Re-run expectations (per cucx-docs's 007):
- 911-CTI-RP / 912 finding (CFNA + CFUR): GONE — Device DN matches
- 912-CTI-RP / 10911 finding: UNCHANGED — Route pattern still
unreachable (CER911-PT not in 911CER-CSS)
- 913-CTI-RP / 60003 finding: UNCHANGED — destination doesn't
exist anywhere
Findings: 6 → 4 (the 4 that actually matter).
Ryan Malloy
c995bc2712