Found while implementing #5137. Filed unassigned and not fixed there: that card is a behaviour change in DatasetReportRenderer.tsx and this is a different defect class (test network isolation) at a file the card only appends to.
Measured on claude/issue-5137-report-filter-alias at e9a7dfb36, whose merge-base is origin/main at 7d900dee6. Pre-existing — nothing in that branch touches the code path.
The escape
packages/plugin-report/src/__tests__/DatasetReportRenderer.test.tsx makes 16 real TCP connection attempts per run to 127.0.0.1:3000:
Error: connect ECONNREFUSED 127.0.0.1:3000
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {
errno: -111, code: 'ECONNREFUSED', syscall: 'connect',
address: '127.0.0.1', port: 3000
}
Bisected across the package — it is that one file, and only that one:
DatasetReportRenderer.test.tsx -> ECONNREFUSED x16
ReportViewer.cells.test.tsx -> ECONNREFUSED x0
ReportRenderer.test.tsx -> ECONNREFUSED x0
ReportRendererDispatcher.test.tsx -> ECONNREFUSED x0
report-spec-parity.test.tsx -> ECONNREFUSED x0
The suite is green anyway (42 passed), which is what makes it worth a card rather than a shrug: the connection failure is swallowed, so whatever assertion sits downstream is passing through an error path rather than the one it names.
Why it is not just noise
- Something reaches a real transport in a unit test.
packages/plugin-report/src contains no fetch( and no literal 3000, and none of the three root setup files (vitest.setup.base.ts, vitest.setup.dom-light.tsx, vitest.setup.dom.tsx) references either — so the call originates in a workspace dependency the vitest aliases resolve to src, reached by a render path where the test's mock data source is not the one consulted. Locating that path is the actual work here.
- The suite depends on nothing listening on port 3000. In this repo's own shared containers a dev server on 3000 is routine. If one is up, those 16 attempts connect — to whatever another agent happens to be running — and the test's behaviour changes without a single line of it changing.
- A green test that quietly took the error path is not testing what it says. Worth checking which of the 42 depend on the swallowed failure.
Family
Same shape as #3339 (plugin-detail), #4106 (plugin-charts / plugin-dashboard, noted there as a different root cause from #3339) and #4688 (plugin-view / app-shell / plugin-designer) — all closed. plugin-report looks like a site those sweeps did not cover. The root cause here has not been established, so it may well be a fourth distinct one; worth checking the closed three before assuming.
Recheck
pnpm exec vitest run packages/plugin-report/src/__tests__/DatasetReportRenderer.test.tsx 2>&1 | grep -c ECONNREFUSED
Related: #5137 (the card this was found under; its PR is #5224 and deliberately leaves this alone).
Found while implementing #5137. Filed unassigned and not fixed there: that card is a behaviour change in
DatasetReportRenderer.tsxand this is a different defect class (test network isolation) at a file the card only appends to.Measured on
claude/issue-5137-report-filter-aliasate9a7dfb36, whose merge-base isorigin/mainat7d900dee6. Pre-existing — nothing in that branch touches the code path.The escape
packages/plugin-report/src/__tests__/DatasetReportRenderer.test.tsxmakes 16 real TCP connection attempts per run to127.0.0.1:3000:Bisected across the package — it is that one file, and only that one:
The suite is green anyway (
42 passed), which is what makes it worth a card rather than a shrug: the connection failure is swallowed, so whatever assertion sits downstream is passing through an error path rather than the one it names.Why it is not just noise
packages/plugin-report/srccontains nofetch(and no literal3000, and none of the three root setup files (vitest.setup.base.ts,vitest.setup.dom-light.tsx,vitest.setup.dom.tsx) references either — so the call originates in a workspace dependency the vitest aliases resolve tosrc, reached by a render path where the test's mock data source is not the one consulted. Locating that path is the actual work here.Family
Same shape as #3339 (plugin-detail), #4106 (plugin-charts / plugin-dashboard, noted there as a different root cause from #3339) and #4688 (plugin-view / app-shell / plugin-designer) — all closed.
plugin-reportlooks like a site those sweeps did not cover. The root cause here has not been established, so it may well be a fourth distinct one; worth checking the closed three before assuming.Recheck
Related: #5137 (the card this was found under; its PR is #5224 and deliberately leaves this alone).