Before tri-state locking we could trouble shoot lock timeouts via telemetry by combining events 'RT0012 - Database lock timeout' and 'RT0013 - Database lock snapshot'.

When we do this we get the information from the victim process and the blocker/perpetrator process.

The information contains the AL-stacktrace which we can act on.

Now with Tri-State Locking we get considerably lower lock timeouts than before BUT we also get less information once the lock timeouts occur.

For example last 1,5 month with our customer with ~600 users we got 1204 lock timeouts but only 389, 30% of them contained stack trace from the blocker!

It is very frustrating for both us and the customer that we can't see what is causing 70% of the lock timeouts.

A suggestion in yammer (https://www.yammer.com/dynamicsnavdev/threads/3284151762870272) is that you should add the sqlServerSessionId or, even better transactionId to telemetry event 'RT0005 - Operation exceeded time threshold (SQL query)' and make sure these exists in RT0012|RT0013 so we can better troubleshoot what is going on when a Lock Timeout occurs.