sp_BlitzLock - Duplicate available plans

[Tisit]

Version of the script
8.28

What is the current behavior?

There are at least 3 scenarios where we can get dupliate entries for available plans from sp_BlitzLock:

1. Procedure involved in deadlock has many queries
2. Procedure is called with different parameters
3. The query involves many tables and deadlock may occur on any of them (I think)

Setup:

DROP TABLE IF EXISTS dbo.LockTest

CREATE TABLE dbo.LockTest (
    Id INT NOT NULL PRIMARY KEY,
    Value INT NOT NULL
);
GO

CREATE OR ALTER PROC p_UpdateLockTest (@p1 int) AS
BEGIN

    SELECT count(1) c into #t2 from sys.indexes

    UPDATE dbo.LockTest
    SET Value = Value + 1
    WHERE Id = @p1;

END

GO

INSERT INTO dbo.LockTest (Id, Value) VALUES (1, 100), (2, 200);
GO

--clean out plan cache to better see the issue
DBCC FREEPROCCACHE()

Session A:

BEGIN TRAN;

EXEC p_UpdateLockTest @p1 = 1

GO

EXEC p_UpdateLockTest @p1 = 2

--ROLLBACK

Session B:

BEGIN TRAN;

EXEC p_UpdateLockTest @p1 = 2

GO

EXEC p_UpdateLockTest @p1 = 1

--ROLLBACK

1. Set up table, procedure and insert data
2. Open 2 sessions A and B
3. In session A start the transaction and execute the first procedure
4. In session B start the transaction and execute the first procedure
5. In session A execute the second procedure. It will hang
6. In session B execute the second procedure. It will succeed or become a deadlock victim
7. execute sp_BlitzLock and observe the available plans

This reproducesr shows first 2 of the issues mentioned. The last one is quite hard to reproduce for me. Sorry.

Even though only one procedure was involved we can see it duplicated 6 times in my case. Some entries are obviosly duplicate of others.
Other seem to provide data for unrelated query from the same procedure. You can see the statistics and statement offfsets are different.

What is the expected behavior?
Only one row is returned for involved statement

Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
Reproduced in SQL 2017, 2019 Pretty sure this is independent from the version

---

I have potential fix for this issue since I stumbled into this in production already:
dd8bc10
If you are interested I can make a pull request and/or explain it a little