test(ci): schedule a mid-test snapshot 150ms after every beforeEach

[JohnMcLear]

Summary

Follow-up to #7838. Schedule an unref'd setTimeout from beforeEach that fires 150 ms after a test enters: if it's still the running test at fire time (i.e. slow enough that the death window applies), capture a node-report from INSIDE the test body.

Why

Run 26401801404 captured the dying test's beforeEach node-report — be-0258, written 75 ms after socketio.ts > Pad-wide settings creator gate different browsers entered — but no further state. The kill landed 321 ms into the test body, between 1 Hz heartbeat ticks, and the 100 ms boundary throttle prevented further beforeEach writes inside the same test. The report we have shows only the listening server socket; the connections that the test body creates (and that presumably precede the kill) never get snapshotted.

What this changes

Pure diagnostic. No behavior change on successful runs.

• mochaHooks.beforeEach schedules setTimeout(150ms) and captures currentTest in closure.
• Timer is unref()-d so it never holds the loop open.
• On fire, if currentTest === enteredTest, write a node-report (prefix mt-). Fast tests (<150 ms) have already moved on — afterEach cleared the pointer — so the write is skipped.

Expected result on next reproduction of the kill pattern

be-NNNN report  +75 ms   (beforeEach, body not yet started)
mt-MMMM report  +150 ms  (mid-test, body in flight, before kill at +320 ms)
kill            +320 ms  (no further reports)

The mt-MMMM snapshot is the V8 stack + libuv handle snapshot we've been chasing — the one with the open TCP / socket.io connections that the kill correlates with.

Cost

Only slow tests (>150 ms) generate an mt- report, so artifact growth is bounded by the count of slow tests — typically a small minority. Most tests fire-and-skip.

Locally verified

3-test probe (10 ms, 300 ms, 5 ms tests):

[diag +9ms]   test start: fast (10ms)
[diag +46ms]  test start: slow (300ms)
[diag +347ms] test start: fast 2

--- files ---
be-0001-fast_10ms.json
mt-0002-slow_300ms.json   ← only the slow test triggered the mid-test write
be-0003-fast_2.json

🤖 Generated with Claude Code

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Add mid-test diagnostic snapshot 150ms after test start

🧪 Tests

Walkthroughs

Description

• Schedule mid-test snapshot 150ms after beforeEach
• Capture node-report from inside test body during execution
• Diagnose slow tests with TCP/socket.io activity
• Fast tests skip write, only slow tests generate reports

Diagram

flowchart LR
  BE["beforeEach hook"] -->|schedule unref'd timer| TIMER["setTimeout 150ms"]
  TIMER -->|fire at 150ms| CHECK{"currentTest still running?"}
  CHECK -->|yes, slow test| REPORT["Write mt-NNNN report"]
  CHECK -->|no, fast test| SKIP["Skip write"]
  REPORT --> DIAG["Capture TCP/socket.io state"]

Loading

File Changes

1. src/tests/backend/diagnostics.ts 🧪 Tests +18/-0

Add mid-test diagnostic snapshot scheduling

• Added mid-test snapshot scheduling in beforeEach hook
• Creates unref'd setTimeout that fires 150ms after test entry
• Checks if test is still running before writing mt- prefixed report
• Captures node-report from inside test body for slow tests only

src/tests/backend/diagnostics.ts

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Mid-snapshot suppresses boundary report ✓ Resolved 🐞 Bug ◔ Observability

Description

The new tryWriteReport('mt', 0) updates the shared lastReportT timestamp, which can cause the next
test's tryWriteReport('be', 100) to be throttled and skipped if it starts within 100ms after the
mid-test snapshot. This reduces boundary report coverage specifically after slow tests (the exact
tests most likely to generate mt reports).

Code

src/tests/backend/diagnostics.ts[R220-222]

Evidence

The mt write is added in beforeEach and calls tryWriteReport('mt', 0). tryWriteReport enforces
throttling via a single shared lastReportT and always sets lastReportT=now on any successful write,
so an mt write can move lastReportT forward and make a subsequent be write fall within the 100ms
suppression window.

src/tests/backend/diagnostics.ts[97-112]
src/tests/backend/diagnostics.ts[192-224]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`tryWriteReport()` uses a single global `lastReportT` for all report types. The newly added mid-test report (`mt`) updates `lastReportT`, which can inadvertently throttle and suppress subsequent boundary reports (`be`) in the next test’s `beforeEach`.
## Issue Context
`beforeEach` always calls `tryWriteReport('be', 100)` and now additionally schedules a mid-test `tryWriteReport('mt', 0)`.
## Fix Focus Areas
- src/tests/backend/diagnostics.ts[97-121]
- src/tests/backend/diagnostics.ts[192-224]
### Suggested fix direction
Introduce separate throttle state for boundary vs. mid-test reports (e.g., `lastBoundaryReportT` for `be` and a different timestamp for `hb/mt`), or add an option so `mt` writes do not advance the timestamp used for `be` throttling.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Unconditional mid-test timer overhead ✓ Resolved 🐞 Bug ➹ Performance

Description

beforeEach schedules a setTimeout for every test even when canWriteReport is false, so the callback
work is guaranteed to be wasted on runs without node-report enabled. This adds unnecessary
timer/callback churn across the whole suite for no possible diagnostic output.

Code

src/tests/backend/diagnostics.ts[R218-224]

Evidence

canWriteReport is the global gate for report writing and tryWriteReport returns immediately when it
is false, but the new code schedules setTimeout regardless, meaning on canWriteReport=false runs the
timer always fires and does only the compare + no-op call path.

src/tests/backend/diagnostics.ts[97-110]
src/tests/backend/diagnostics.ts[192-224]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new mid-test snapshot timer is scheduled unconditionally, but the callback can never produce a report when `canWriteReport` is false because `tryWriteReport()` returns immediately.
## Issue Context
`canWriteReport` already gates report writing, but the timer is still created per test.
## Fix Focus Areas
- src/tests/backend/diagnostics.ts[97-110]
- src/tests/backend/diagnostics.ts[192-224]
### Suggested fix direction
Only schedule the 150ms `setTimeout` when `canWriteReport` is true (or inline-check before scheduling). This preserves the diagnostic behavior in CI configurations that enable node-report while avoiding per-test timers in runs where reports are disabled.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---