Read blocking-chain typed columns instead of re-parsing XML#998
Merged
erikdarlingdata merged 1 commit intoMay 27, 2026
Merged
Conversation
The Dashboard fact collector and drill-down collector now read the typed blocker-side columns added in #996 (blocking_spid, blocking_last_tran_started, blocking_status, blocked_sql_text, blocking_sql_text) directly from collect.blocking_BlockedProcessReport instead of re-parsing blocked_process_report_xml on every analysis cycle — up to 5000 XElement.Parse calls per BLOCKING_CHAIN fact collection are eliminated. BlockedProcessXmlParser is deleted; no callers remain. Lite is unchanged — it has no SQL-side staging table and continues to parse once at collect time inside RemoteCollectorService.BlockedProcessReport. Both SELECTs add `AND blocking_spid IS NOT NULL` so rows whose source XML carried an empty <blocking-process><process/></blocking-process> (system tasks, torn-down sessions) are filtered out — they can't contribute to a reconstructed chain. The old parser silently produced BlockingSpid = 0 for those rows, which the reconstructor's self-edge check then rejected anyway. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
erikdarlingdata
deleted the
feature/dashboard-blocking-chain-typed-columns
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
collect.blocking_BlockedProcessReport(added in Add typed blocker-side columns to blocking_BlockedProcessReport #996) instead of re-parsingblocked_process_report_xmlon every analysis cycle — eliminates up to 5000XElement.Parsecalls perBLOCKING_CHAINfact collection.Dashboard/Analysis/BlockedProcessXmlParser.csdeleted; no callers remain.AND blocking_spid IS NOT NULL, dropping rows whose source XML had an empty<blocking-process><process/></blocking-process>(system tasks / torn-down sessions). Those rows can't contribute to a reconstructed chain — the old parser silently producedBlockingSpid = 0for them, which the reconstructor rejected as a self-edge anyway.RemoteCollectorService.BlockedProcessReport.This is PR (b) of the SQL-side blocked-process-pair workstream. PR (a) was #996.
Test plan
dotnet build Dashboard/Dashboard.csproj -c Debug— clean, 0 warnings, 0 errorsdotnet test Lite.Tests/Lite.Tests.csproj— 260/260 passing (Lite untouched; cross-check)git grep -n BlockedProcessXmlParser -- 'Dashboard/**' 'Lite/**'returns zero hitsBlockingPairRowmapping verified across all 11 columns; types align with schema; NULL fallbacks match field defaults)BlockingChainReconstructor.csnot touched on this branchBLOCKING_CHAINfinding still produces the expected apex/depth/victims🤖 Generated with Claude Code