Feature/add alert filter by database

[HannahVernon]

What does this PR do?

Adds the ability to filter certain alert features by database name:

• Deadlocks
• Long Running Queries

Which component(s) does this affect?

• [✅] Full Dashboard
• [✅] Lite Dashboard

How was this tested?

Tested deadlock alerts with a classic "lock resources in opposite order" deadlock test in a dedicated database. With the database name included in the exclusion list, the alert is not fired when a deadlock occurs. With the database not present in the exclusion list, the deadlock alert is fired as expected.

Tested long running queries with the execution-database both in the list and not in the list - exclusion works as expected.

Checklist

• [✅] I have read the contributing guide
• [✅] My code builds with zero warnings (dotnet build -c Debug)
• [✅] I have tested my changes against at least one SQL Server version
• [✅] I have not introduced any hardcoded credentials or server names

[erikdarlingdata]

Thanks for this, Hannah! Really nice feature — database-level alert exclusions are something folks have been asking about. Clean implementation across both Dashboard and Lite, and the testing sounds thorough. A few things I noticed:

---

1. Deadlock alert fires on unfiltered count (Dashboard)

The deadlock tray notification is triggered by health.DeadlockCount, which comes from GetDeadlockCountAsync — that query is never filtered by excluded databases. The BuildDeadlockContextAsync filtering only affects the email context body. So a deadlock in an excluded database will still trigger the tray alert, but the email will correctly omit it. This is inconsistent with how blocking and long-running queries work, where the filtering happens before the threshold check.

2. Lite is missing deadlock and blocking filtering

The Lite side only filters long-running queries. If Lite has deadlock and blocking alert paths, those aren't getting the exclusion filter applied. The Dashboard covers all three.

3. Unrelated change to max results clamp

In Lite/App.xaml.cs, the alert_long_running_query_max_results clamp was changed from Math.Clamp(v.GetInt64(), 1, 1000) to Math.Clamp(v.GetInt64(), 1, int.MaxValue). That removes the safety cap and seems unrelated to this PR.

4. Settings help text is incomplete

Both Dashboard and Lite say "applies to long-running query and blocking alerts" but the Dashboard also applies it to deadlocks (partially). Should probably mention deadlocks too, or clarify the actual scope once the filtering is consistent.

[HannahVernon]

Sorry for the partially incorrect PR. Will fix, likely tomorrow, and update the PR.

[HannahVernon]

@erikdarlingdata - here's a summary of the changes I made today:

Four issues addressed across three commits:

---

1. Dashboard deadlock alert firing on unfiltered count (f41d087)

GetDeadlockCountAsync reads from sys.dm_os_performance_counters, which is server-wide and cannot be filtered by database. Added a new GetFilteredDeadlockCountAsync method that instead queries collect.blocking_deadlock_stats — summing
deadlock_count_delta over a 5-minute window (matching AlertCooldown), excluding configured databases. When excluded databases are configured, EvaluateAlertConditionsAsync uses this filtered count (effectiveDeadlockDelta) for the
threshold check, tray notification, RecordAlert, and email currentValue. The raw perf counter tracking (_previousDeadlockCounts) is left untouched.

---

2. Lite missing deadlock and blocking filtering (5e41b5d)

CheckPerformanceAlerts was using summary.BlockingCount and summary.DeadlockCount (both unfiltered server-wide counts) directly against thresholds. Fixed to mirror the existing long-running query pattern:

• Blocking: when excluded databases are configured and the raw count is at or above threshold, fetches GetRecentBlockedProcessReportsAsync and filters in-memory by DatabaseName. Uses effectiveBlockingCount for the threshold check,
  tray notification, and email value.
• Deadlocks: same approach using GetRecentDeadlocksAsync, filtered via a new IsDeadlockExcluded helper that parses each deadlock's XML and excludes a deadlock only when every process node's currentdbname is in the excluded list
  (cross-database deadlocks still fire).
• BuildBlockingContextAsync and BuildDeadlockContextAsync also now filter by excluded databases so email alert bodies are consistent with tray notifications.

---

3. Restore safety cap on alert_long_running_query_max_results (746591a)

The Math.Clamp upper bound had been accidentally changed from 1000 to int.MaxValue. Restored to 1000.

---

4. Settings help text updated (781069f)

Both Dashboard and Lite SettingsWindow.xaml hint text updated from "applies to long-running query and blocking alerts" to "applies to blocking, deadlock, and long-running query alerts" to accurately reflect all three alert types.

[erikdarlingdata]

Code Review — 4 Items

1. GetFilteredDeadlockCountAsync catch block should return null, not 0

File: Dashboard/Services/DatabaseService.NocHealth.cs, line ~260 in the new method

Problem: The catch block returns 0, which gets assigned to FilteredDeadlockCount. In MainWindow.xaml.cs, the alert logic does:

var effectiveDeadlockDelta = health.FilteredDeadlockCount ?? deadlockDelta;

When FilteredDeadlockCount is 0 (from the catch), it's not null — so the fallback to deadlockDelta never happens. This means real deadlock alerts get silently suppressed if the query fails (e.g., older schema without collect.blocking_deadlock_stats, permissions issue, timeout).

Fix: Change the return type to Task<long?> and return null from the catch block. This way a failure falls back to the raw performance counter delta and deadlock alerts still work:

catch (Exception ex)
{
    Logger.Warning($"Failed to get filtered deadlock count: {ex.Message}");
    return null;  // Fall back to raw delta
}

Then update the method signature and the assignment in GetAlertHealthAsync accordingly.

---

2. SQL string interpolation should use parameterized queries

Files:

• Dashboard/Services/DatabaseService.NocHealth.cs — GetBlockingValuesAsync (line ~215)
• Dashboard/Services/DatabaseService.NocHealth.cs — GetFilteredDeadlockCountAsync (line ~243)

Problem: Both methods build SQL with string interpolation:

var dbFilter = string.Join(", ", excludedDatabases.Select(db => $"N'{db.Replace("'", "''")}'"));

The Replace("'", "''") escaping works, but string-built SQL is fragile and doesn't follow the pattern used everywhere else in the codebase (parameterized SqlCommand with @param placeholders). The values come directly from user input in the Settings text box.

Fix: Use sp_executesql with a comma-separated parameter and STRING_SPLIT, or build individual @db0, @db1, @db2 parameters dynamically:

var dbParams = new List<string>();
for (int i = 0; i < excludedDatabases.Count; i++)
{
    var paramName = $"@exdb{i}";
    dbParams.Add(paramName);
    cmd.Parameters.AddWithValue(paramName, excludedDatabases[i]);
}
var dbFilter = $"AND DB_NAME(s.dbid) NOT IN ({string.Join(", ", dbParams)})";

This matches the parameterized pattern used by every other query in DatabaseService.*.cs.

---

3. Settings UI placement is misleading

Files:

• Dashboard/SettingsWindow.xaml (line ~280)
• Lite/Windows/SettingsWindow.xaml (line ~207)

Problem: The "Database Exclusions" section is placed inside the long-running query options area — between the LRQ exclude checkboxes and the TempDB space checkbox. But this setting applies to blocking, deadlocks, AND long-running queries. Users will either miss it or think it only applies to long-running queries.

Fix: Move the "Database Exclusions" section to its own visually distinct group, either:

• Above the individual alert type settings (blocking, deadlock, LRQ), since it's a cross-cutting filter
• Or below all alert type settings as a "Global Alert Filters" section

In both XAML files, move the TextBlock + TextBox + helper text block to a position that makes its scope obvious. The helper text already says "applies to blocking, deadlock, and long-running query alerts" which is good — it just needs to not be visually nested under the LRQ section.

---

4. Verify Dashboard DeadlockItem.DatabaseName is populated

File: Dashboard/MainWindow.xaml.cs — BuildDeadlockContextAsync (line ~106 in diff)

Problem: The deadlock filtering in Dashboard does:

deadlocks = deadlocks
    .Where(d => string.IsNullOrEmpty(d.DatabaseName) ||
        !excludedDatabases.Any(e =>
            string.Equals(e, d.DatabaseName, StringComparison.OrdinalIgnoreCase)))
    .ToList();

This assumes DeadlockItem (or whatever model GetDeadlocksAsync returns) has a DatabaseName property that's populated with the database where the deadlock occurred.

Check: Does the GetDeadlocksAsync query actually return a database_name column and map it to this property? If DatabaseName is always null/empty, the string.IsNullOrEmpty(d.DatabaseName) check means every deadlock passes the filter and nothing ever gets excluded.

Compare with the Lite implementation which correctly parses the deadlock graph XML to extract currentdbname from process nodes — that approach works regardless of whether the collector stores a separate database_name column. If Dashboard's model doesn't have this field populated, you'll need the same XML parsing approach (see IsDeadlockExcluded in Lite/MainWindow.xaml.cs).

How to verify: Check the query in DatabaseService.Blocking.cs or wherever GetDeadlocksAsync is defined — look for whether database_name is in the SELECT list and mapped to the model.

[HannahVernon]

Thanks for bearing with me through this review, Erik.

Fixes for items 1 through 4 have been implemented.

1. GetFilteredDeadlockCountAsync catch block returns null, not 0, and the method signature is updated.

2. SQL string interpolation has been changed out with explicit T-SQL parameterization in the full Dashboard. Checked how the query would look for cases with an empty excludedDatabases list, as well as one containing msdb against both GetFilteredDeadlockCountAsync() and GetBlockingValuesAsync() methods.

3. Settings UI placement is misleading -> added a section called "Global Alert Filters", and moved the "Database Exclusions" text box into that section. Fired up the Dashboard and inspected the layout of the settings window - looks much better to me.

4. checking excluded databases in GetDeadlocksAsync() is now filtering via the deadlock graph in BuildDeadlockContextAsync() instead of just the database_name column.

---

I asked Github Copilot to do a comprehensive review:

The user wants a final comprehensive re-audit. Let me get the complete diff again and systematically review everything. Since we just did a thorough audit and only added two small lines, I should still be thorough but can focus on
confirming the previous findings still hold plus verifying the new changes.

● Final audit: 32 PASS, 2 WARN, 0 FAIL.

The two WARNs are design notes, not bugs:

1. Deadlock delta window mismatch — FilteredDeadlockCount uses a fixed 5-minute SQL window vs. the polling-interval raw delta. Already documented in the code comments as intentional.
2. Dashboard vs Lite filtering architecture — Dashboard filters blocking at SQL level; Lite filters client-side. Both correct, just different due to their data access patterns.

No errors found. All SQL queries, null handling, filtering logic, edge cases, and settings persistence are correct across both editions.