Fix sp_BlitzLock parallel deadlock filtering regression

[BrentOzar]

Summary

• Restores ROW_NUMBER() - 1 (0-based) for the qn column in sp_BlitzLock, which was accidentally changed to 1-based ROW_NUMBER() in PR 2026-04-06 Release #3885.
• Without the - 1, downstream code breaks in two ways:
  • Parallel deadlock filtering (d.qn < 2): only keeps 1 row instead of 2, silently dropping the second query involved in the deadlock.
  • Deadlock group labeling (WHEN d.qn = 0): this branch becomes dead code since qn never equals 0.

Test plan

• Verified with a query that the 0-based qn correctly keeps 2 rows for qn < 2 (parallel deadlock filter), while 1-based only keeps 1.
• Verified WHEN d.qn = 0 THEN N'1' branch is reachable with 0-based numbering.
• Deployed to local SQL Server instance successfully.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Restores the intended 0-based qn numbering in sp_BlitzLock so that parallel deadlock filtering and related downstream logic behave correctly after a prior regression.

Changes:

• Change qn to be 0-based again by using ROW_NUMBER() ... - 1 in both deadlock-process projections (regular + parallel).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

qn is now 0-based (ROW_NUMBER() - 1), but downstream formatting later builds deadlock_group with CASE WHEN d.qn = 0 THEN '1' ELSE CONVERT(..., d.qn) END, which will label both qn=0 and qn=1 as "Query #1". Update the consumer to display d.qn + 1 (or otherwise adjust) so query numbering remains correct, especially for parallel deadlocks where only qn<2 rows are kept.

[Copilot]

The ROW_NUMBER() uses ORDER BY dp.event_date inside PARTITION BY dp.event_date, which is non-deterministic because all rows in the partition have the same ordering key. Since qn is used to filter parallel deadlocks to the first 2 rows, consider ordering by a stable discriminator (e.g., dp.id and/or dp.spid) to ensure consistent row selection.

Suggested change

	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.event_date) - 1,
	dn =
	ROW_NUMBER() OVER (PARTITION BY dp.event_date, dp.id ORDER BY dp.event_date),
	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.id, dp.spid) - 1,
	dn =
	ROW_NUMBER() OVER (PARTITION BY dp.event_date, dp.id ORDER BY dp.spid, dp.id),

[Copilot]

Same as earlier: with qn now 0-based, the later deadlock_group label logic (WHEN d.qn = 0 THEN '1' ELSE CONVERT(..., d.qn)) will mislabel qn=1 as "Query #1". Adjust the label computation to use d.qn + 1 (or equivalent) so output query numbering stays correct.

Suggested change

	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.event_date) - 1,
	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.event_date),

[Copilot]

Same non-determinism here: ROW_NUMBER() orders by dp.event_date while partitioning by dp.event_date, so qn assignment can change between runs/plans. Because later logic filters qn < 2 for parallel deadlocks, order by a stable column (e.g., dp.id, dp.spid) to make the filter deterministic.

Suggested change

	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.event_date) - 1,
	dn =
	ROW_NUMBER() OVER (PARTITION BY dp.event_date, dp.id ORDER BY dp.event_date),
	ROW_NUMBER() OVER (PARTITION BY dp.event_date ORDER BY dp.id, dp.spid) - 1,
	dn =
	ROW_NUMBER() OVER (PARTITION BY dp.event_date, dp.id ORDER BY dp.spid),