incident_correlator.py, the unit-continuity block (~line 630, corr_debug = {"corr_path": "unit-continuity", "corr_incident_idle_min": ...}) never sets corr_matched_units, unlike fast/single and fast/disambig which call _matching_units(call_units, candidate.get("units")) and populate it whenever fit_signal == "unit_overlap".
Confirmed against production data: every corr_path == "unit-continuity" call in a 100-incident debug_correlation() pull (4 of 4) has corr_matched_units: null, even though the match was in fact unit-driven (verified by re-implementing _normalize_unit/_matching_units locally and intersecting each call's units against its incident's other calls - e.g. incident a8c74c13 call a930bcff (units=["Post 1-2"]) matched anchor call 06a37b07 (units=["5-4","9-0-8","1-2"]) via the normalizer collapsing "Post 1-2" and "1-2" to the same key "12" - real evidence the c09cb72 normalizer change is working, but invisible in /admin/debug/correlation because the field is blank).
This makes the debug view actively misleading for this path: an operator auditing why two calls merged via unit-continuity sees corr_matched_units: null and has no way to tell, from the API response alone, which unit(s) triggered the link. Low severity (doesn't affect correlation behavior, only observability) but a one-line fix: compute _matching_units(call_units, best_unit_inc.get("units")) and add it to that corr_debug dict the same way the other two paths do.
`incident_correlator.py`, the unit-continuity block (~line 630, `corr_debug = {"corr_path": "unit-continuity", "corr_incident_idle_min": ...}`) never sets `corr_matched_units`, unlike `fast/single` and `fast/disambig` which call `_matching_units(call_units, candidate.get("units"))` and populate it whenever `fit_signal == "unit_overlap"`.
Confirmed against production data: every `corr_path == "unit-continuity"` call in a 100-incident debug_correlation() pull (4 of 4) has `corr_matched_units: null`, even though the match was in fact unit-driven (verified by re-implementing `_normalize_unit`/`_matching_units` locally and intersecting each call's `units` against its incident's other calls - e.g. incident `a8c74c13` call `a930bcff` (units=["Post 1-2"]) matched anchor call `06a37b07` (units=["5-4","9-0-8","1-2"]) via the normalizer collapsing "Post 1-2" and "1-2" to the same key "12" - real evidence the c09cb72 normalizer change is working, but invisible in `/admin/debug/correlation` because the field is blank).
This makes the debug view actively misleading for this path: an operator auditing why two calls merged via unit-continuity sees `corr_matched_units: null` and has no way to tell, from the API response alone, which unit(s) triggered the link. Low severity (doesn't affect correlation behavior, only observability) but a one-line fix: compute `_matching_units(call_units, best_unit_inc.get("units"))` and add it to that `corr_debug` dict the same way the other two paths do.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
incident_correlator.py, the unit-continuity block (~line 630,corr_debug = {"corr_path": "unit-continuity", "corr_incident_idle_min": ...}) never setscorr_matched_units, unlikefast/singleandfast/disambigwhich call_matching_units(call_units, candidate.get("units"))and populate it wheneverfit_signal == "unit_overlap".Confirmed against production data: every
corr_path == "unit-continuity"call in a 100-incident debug_correlation() pull (4 of 4) hascorr_matched_units: null, even though the match was in fact unit-driven (verified by re-implementing_normalize_unit/_matching_unitslocally and intersecting each call'sunitsagainst its incident's other calls - e.g. incidenta8c74c13calla930bcff(units=["Post 1-2"]) matched anchor call06a37b07(units=["5-4","9-0-8","1-2"]) via the normalizer collapsing "Post 1-2" and "1-2" to the same key "12" - real evidence thec09cb72normalizer change is working, but invisible in/admin/debug/correlationbecause the field is blank).This makes the debug view actively misleading for this path: an operator auditing why two calls merged via unit-continuity sees
corr_matched_units: nulland has no way to tell, from the API response alone, which unit(s) triggered the link. Low severity (doesn't affect correlation behavior, only observability) but a one-line fix: compute_matching_units(call_units, best_unit_inc.get("units"))and add it to thatcorr_debugdict the same way the other two paths do.