[erikdarlingdata]

What users see change

The Darling server page's "partial window" note now covers fourteen more event reads, on data answers and on empty answers alike:

• System Events: the nine get_health_parser_* reads.
• SQL Server: Blocking (get_blocking), Deadlocks (get_deadlocks) and Deadlock Graphs (get_deadlock_detail).
• PostgreSQL: Deadlocks (get_pg_deadlocks) and Log Events (get_pg_log_events).

Before this, an empty System Events panel over a window the store never covered showed nothing. The tool's own keys sat under hints, which the page doesn't read. Now the web writes its own note, in the browser's zone.

How the note is decided

• These are event lists, so the note follows the event-time rule Web: the event grids' data-start note uses the earliest event shown (part of #4966) #5197 introduced: the earlier of the store's coverage start and the earliest event shown. That's the desktop viewer's ViewerEventDataStart.Of. A first collection can store events from before itself.
• A page cut by its row cap names its oldest row shown, without asking the store.
  • The system-health reads are capped when their count of qualifying events (total_entries, error_count, issue_count, event_count or wait_count) exceeds shown, and their oldest row is the minimum event_time.
  • The SQL Server tools carry their oldest field and order word.
  • PostgreSQL: the deadlock page is capped through truncated and its rows' occurred_at; the log page through oldest_returned_at.
• get_blocking is fed by two tables, the blocked process reports and the DMV blocking snapshots. Its probe asks both, and the earlier start wins, as the MCP tool and the desktop viewer do (a new composite source, CompositeSourcesByRead).
• Statuses:
  • Admitted as "looked and found nothing": empty, PostgreSQL's no_deadlocks and no_events.
  • Not admitted: unavailable with source_observed:false.
  • Scope of the PostgreSQL row words: events and deadlocks are row words for their own read only.
• No page change:
  • the system-health CPU line is a chart, which draws no note;
  • the per-deadlock processes sub-grid is a cell, not a panel, so it never draws one.

Test plan

• No store:
  • a theory over the nine system-health reads: capped, uncapped, empty and unavailable;
  • a capped page for each of the five other reads;
  • the capped set pinned at exactly twenty reads;
  • source scans tying each listed read to its tool.
• Live, against a PostgreSQL store, with event times stamped apart from collection_time:
  • the event-time pair (history reaching back before coverage names the earliest event; history reaching the window's start gives no note) on two system-health reads and on each of the five other reads;
  • get_blocking with rows only in the DMV snapshots and only in the XE reports, each naming its own table's start.
• RED:
  • the system-health half: 12 of 28 failed before its dictionary entries;
  • the Blocking, Deadlocks and PostgreSQL half: the tests were written after the code, and six failed on their first run (an exact-set pin, a source pin, two counts, two live seeds) before they were fixed.
• On the combined branch:
  • --no-incremental build: 0 warnings;
  • every WebDataStartNote* class plus SeparatelyMonitoredListNoteTests: 135 tests, 0 failed;
  • every Darling.Tests class that names a changed file, and every class that reads repository source: every failure is one that fails only on macOS;
  • the live-store collection check, emulated on macOS: 0 offenders.

CHANGELOG

SECTION: Fixed
ENTRY: - The web page's System Events, Blocking, Deadlocks and PostgreSQL event panels say where their data starts ([#5222]) - fourteen event reads now show the partial-window note when the store's history starts after the window starts, on empty answers too: the earlier of the coverage start and the earliest event shown, or a capped page's oldest row. Blocking probes both of its sources, as the desktop does.
REF: [#5222]: #5222

Part of #4966