Repository navigation
[BUG] Multi-incident alerts (Deadlocks Detected) serialize as a flat, un-grouped FactSet — emit each incident as a self-contained unit #2108
Description
Component
Darling
Performance Monitor Version
Darling 3.3.0
SQL Server Version
n/a
Windows Version
n/a
Describe the Bug
Environment: Darling 3.3.0, webhook → Teams / Azure Logic App.
What happens: when one alert aggregates several incidents - a burst of deadlocks collapsing into multiple #1140 fingerprints — sections[0].facts[] comes through as one flat list: every Victim SQL/Processes pair first, then each Dedup Key followed by its Involved Objects, with Occurrences interleaved. Real example (3 events, 2 fingerprints):
Victim SQL / Processes (×3, no incident label)
Dedup Key e7d9559c… / Involved Objects smModel…TeamGk.dbo.T2, …T3
Occurrences 2
Dedup Key 908d2df… / Involved Objects smModel…TeamGk.dbo.T1, …T2
Problem: a Victim SQL/Processes pair can't be associated with its Dedup Key/Involved Objects — they're in different parts of the list. In Teams it reads as one long undifferentiated block ("which deadlock is which?"), and downstream automation (Logic App → Azure DevOps) can't split into per-incident work items because the victim→fingerprint mapping is gone.
Steps to Reproduce
Generate two different deadlocks.
Expected Behavior
Request: render each incident as a self-contained, labeled unit — ideally one sections[] entry per incident (each carrying its own Victim SQL, Processes, Dedup Key, Involved Objects), or failing that, keep one section but group facts per incident with an index ("Deadlock 1 of 2") and each incident's Dedup Key/Involved Objects adjacent to its own Victim SQL/Processes.
Benefit: readable multi-incident Teams cards, and downstream tooling can open one correctly-scoped ticket per incident.
Actual Behavior
Error Messages / Log Output
Screenshots
No response
Additional Context
No response
Activity
erikdarlingdata commentedon Aug 7, 2026
Verified, and the diagnosis lands one layer deeper than the symptom suggests: the internal model already keeps each incident as a self-contained unit — since #1141 every deadlock incident carries its own Victim SQL/Processes fields, and the display items are per-unit with their own headings. The flattening happens only at the Teams serializer:
BuildTeamsPayloadpours every detail item's fields into onefactslist inside a singlesections[0], which is exactly the undifferentiated block in your screenshot.So the fix is your preferred option, and it's compact: one
sections[]entry per detail item, with the item's heading as that section'sactivityTitle(the incident label) and only that item's fields as itsfacts. MessageCard renders each section with its own header and fact block, so the victim→fingerprint association survives visually and structurally, and your Logic App can split onsections[]to open one work item per incident. Fact names don't change.One compatibility note, since you're parsing this downstream: anything keyed specifically on
sections[0].facts[]containing all facts would need to iteratesections[]after this ships. That seems like the trade you're explicitly asking for, but flagging it so it isn't a surprise.Planned alongside #2109 (the discrete Database fact), since they touch the same deadlock payload — the Database fact will land per-incident here, which is exactly where your automation wants it.
erikdarlingdata commentedon Aug 7, 2026
Shipped via #2110, merged to dev — each fingerprinted deadlock is one self-contained item (Database / Victim SQL / Processes / Dedup Key / Involved Objects / Occurrences, headed "Deadlock N of M"), and the Teams payload gives every fields-carrying item its own sections[] entry. Your Logic App can split on sections[] to open one work item per incident. Reminder on the one shape change: consumers keyed on sections[0].facts[] holding every fact should iterate sections[] once this reaches you in the next release. Thanks for the precise report — the internal model already had the association (#1141); it was the serializer flattening it.
Multi-incident alerts render as self-contained units; every database-…