Lite and Darling drop Extended Events sessions that another install still reads #4961

Problem

Lite and Darling create their Extended Events sessions under fixed names that every install shares:

• PerformanceMonitor_LongQueryCompletions, the long-query trace
• PerformanceMonitor_Deadlock
• PerformanceMonitor_BlockedProcess

The deprecated Dashboard also creates the deadlock and blocked-process sessions. Because the names are shared, one install can drop a session that another install still reads. Four paths do this:

1. The long-query trace is off by default, and an install with the trace off drops the session.
   • Lite drops it on its first collection cycle after it starts, on each server where the trace is off.
   • Darling drops it each time it connects to such a server. It connects at service start, after each reconnect, and after each change to the server's definition.
   • So adding a server to an install that has default settings drops the session of any other install that has the trace on.
2. On Azure SQL Database, an install with the trace on drops the session in databases outside its monitored set (On Azure SQL Database, the long-query trace runs only in monitored databases and no longer drops a session another registration still uses #4944). Lite and Darling can monitor different databases of the same server.
3. On Azure SQL Database, an install checks whether it can see each of its sessions in sys.dm_xe_database_sessions. If it cannot see one, it drops the session and creates it again ([QUESTION] About deadlocks, generic webhook #1535). A session that another login created is not visible to this login. So two installs that connect with different logins drop each other's sessions in turn. This path applies to all three names.
4. Darling's --drop-xe-sessions drops all three names, so it also removes sessions that Lite and the Dashboard read. The Dashboard's uninstall script drops the deadlock and blocked-process sessions that Lite and Darling read.

Impact

• The install that lost its session reads zero rows, and each collection run still records success. No warning appears.
• The events that the dropped session held and that nothing had read yet are lost.
• How long the gap lasts depends on the install that lost the session:
  • Lite creates a missing session again on its next collection cycle.
  • Darling 3.9.0 and earlier creates it again only on its next connect to the server. That can be days later.
  • With On Azure SQL Database, the long-query trace runs only in monitored databases and no longer drops a session another registration still uses #4944, Darling creates a missing long-query session again within an hour. It still creates a missing deadlock or blocked-process session again only on its next connect.

Where it happens

The sessions exist on SQL Server, Azure SQL Managed Instance, Amazon RDS and Azure SQL Database. The affected setups include:

• Lite and Darling that monitor the same server.
• Two Lite installs that monitor the same server, for example on two desktops.
• Two Darling stores that monitor the same server, for example while the server moves from one store to the other.

Fix direction

• Lite and Darling stop dropping a session that another install reads, on every engine, and change together.
• The old shared names get a cleanup that cannot remove a session that an older Lite or Darling, or the Dashboard, still reads.
• Before code starts, a design plan answers three questions:
  • How do two installs of the same app keep their sessions apart?
  • How are the old names cleaned up while older versions still run?
  • Which sessions are in scope?