Add items to the Settings Window for Long Running Queries alerts#408
Add items to the Settings Window for Long Running Queries alerts#408HannahVernon wants to merge 21 commits into
Conversation
…_DIAGNOSTIC wait types, and WAITFOR wait types.
…to allow future configurability on the number of long-running queries returned. Added optional parameter to control display of WAITFOR types in future.
…n instead of janky string addition.
…clusions Feature/long running query exclusions
…c() method. Removed System.Collections.Generic using statement as it is unnecessary.
…KUPTHREAD-to-long-running-queries Added exclusion for backup-related waits to GetLongRunningQueriesAsync() method.
…dded miscWaitsFilter to exclude XE_LIVE_TARGET_TVF waits. Removed unused parameters. Corrected minimum value for maxLongRunningQueryCount (minimum 1 instead of 5).
…KUPTHREAD-to-long-running-queries Feature/add exclusion for backupthread to long running queries
…ITFOR, BACKUPTHREAD, BACKUPIO, and XE_LIVE_TARGET_TVF wait types in Lite/Services/LocalDataService.WaitStats.cs
…ries-monitor-changes-to-lite Added filtering for various wait types to long running query code in Lite.
Adds LongRunningQueryMaxResults to UserPreferences (default 5) and exposes it in the Settings UI alongside the existing duration threshold. Threads the value through GetAlertHealthAsync and GetLongRunningQueriesAsync to replace the hardcoded TOP(5) in the DMV query. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Adds Math.Clamp(1, int.MaxValue) guard to GetLongRunningQueriesAsync in both Dashboard and Lite, and updates the Dashboard settings validation to use an explicit range check with a descriptive error message. Mirrors the LongRunningQueryMaxResults setting across the Lite project: adds the App property, loads/saves it to settings.json, exposes it in the Lite Settings UI, and passes it through to GetLongRunningQueriesAsync to replace the hardcoded LIMIT 5. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Prevents an OverflowException if the value in settings.json is outside the int32 range. The value is read as long, clamped to [1, int.MaxValue], then cast back to int. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replaces hardcoded wait type exclusions in GetLongRunningQueriesAsync with user-configurable booleans for SP_SERVER_DIAGNOSTICS, WAITFOR / BROKER_RECEIVE_WAITFOR, backup waits, and miscellaneous waits. All four filters default to true (existing behavior preserved). Settings are exposed in the Notifications section of both Dashboard and Lite Settings UIs and persisted to UserPreferences / settings.json. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…config-settings Feature/long running queries config settings
…config-settings Feature/long running queries config settings
erikdarlingdata
left a comment
erikdarlingdata
left a comment
There was a problem hiding this comment.
Nice work Hannah — clean implementation, both apps stay in sync, and defaults preserve backward compatibility.
A few notes:
1. maxResults clamp is a no-op
Math.Clamp(maxResults, 1, int.MaxValue) doesn't do anything since an int can never exceed int.MaxValue. Same with the Dashboard validation check lrqMaxResults <= int.MaxValue — always true. Should probably cap at something reasonable like 100 or 1000 so someone doesn't accidentally type 999999999 and blow up their alert check.
2. maxResults could be parameterized
The value is interpolated directly into the query string (SELECT TOP({maxResults}) in Dashboard, LIMIT {maxResults} in Lite). It's an int so it's safe in practice, but parameterizing it would be more consistent with how thresholdMinutes is handled.
3. PR branch
Head and base are both dev — this will need to come from a feature branch to actually merge.
4. Minor
Extra blank line in LocalDataService.WaitStats.cs after the filter assignments (around line 226).
|
Regarding |
2 participants
Adds config options to control various aspects of GetLongRunningQueriesAsync() method.
Which component(s) does this affect?
How was this tested?
Tested against SQL Server 2019 and SQL Server 2022 standalone instances.
Checklist