Repository navigation
[BUG] Database exposed as a discrete alert fact on only 2 of the database-scoped alerts #2109
Description
Component
Darling
Performance Monitor Version
3.3.0
SQL Server Version
SQL Server 2022
Windows Version
Windows Server 2022
Describe the Bug
The alert/webhook payload exposes a discrete Database fact for only Blocking Detected and Long-Running Query (AlertContextBuilders.cs:84 and :245). Other database-scoped alerts carry the database name only inside a heading or free text, so a downstream consumer can't read it as a field:
- Deadlocks - database(s) appear only inside Involved Objects (smModel_20260727_TeamGk.dbo.T1), never as a Database fact.
- Version Store / PVS -database is in the heading ("{db} - PVS X%"), not a field.
- Database State and AG Database Suspended / AG Sync Fell Behind - database is in the message text only.
- This blocks routing/tagging by database and populating a Database field on the work items our Logic App creates.
Steps to Reproduce
- Trigger a blocking event and a deadlock on a monitored instance.
- Inspect each alert's webhook payload sections[0].facts[].
- Blocking has { "name": "Database", "value": "…" }; the deadlock has no Database fact — only Involved Objects.
Expected Behavior
Every database-scoped alert emits the same discrete ("Database", ) fact that Blocking and Long-Running Query already add. For deadlocks (which can span databases), a comma-separated list of the distinct databases parsed from the involved objects is perfectly fine.
Actual Behavior
Only Blocking and Long-Running Query add the Database field; Deadlocks, Version Store, Database State, and the AG database alerts expose the database only in the heading/message text.
Error Messages / Log Output
Screenshots
No response
Additional Context
No response
Activity
erikdarlingdata commentedon Aug 7, 2026
All four claims verified in source:
currentdbnameper process and we already parse it (the excluded-database filter). A distinct, comma-separated list per deadlock is derivable exactly as you suggest.{db} — PVS X% of database).Context: null; the database name lives only in the title and prose detail text.Plan, all additive (no existing fact changes, so nothing downstream breaks): the same discrete
("Database", <name>)fact Blocking and Long-Running Query already emit, added per-unit — each deadlock victim item and each fingerprint incident gets the distinct database list from its own graph; each PVS database item gets its own; Database State and the two AG alerts gain a minimal context carrying the fact. Lands together with #2108's per-incident sections, so the deadlock Database fact arrives already scoped to its incident.erikdarlingdata commentedon Aug 7, 2026
Shipped via #2110, merged to dev — discrete (Database, …) facts on deadlocks (distinct databases parsed from the graph's process list, comma-separated when one spans databases), PVS items, Database State (structured context where there was none), and both AG database alerts (Database / Availability Group / Replica, plus Suspend Reason where it applies) through one shared builder in both SKUs so the fact names can't drift. All additive — nothing your existing parsing keys on changes. Rides the next nightly and the next release.
Multi-incident alerts render as self-contained units; every database-…
Put Database and LastEventUtc on the incident projection (#2361) (#2368)
Stop two engine alerts delivering their facts twice, and offer the ne…
Stop the pending database-state alert stating its missing baseline twice