HarperFast / HarperFast/harper
Flaky: 'Harper produced no startup output for 60000ms' — recurring integration-test startup hang, 5x in one morning across unrelated PRs
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 200
Description
## Symptom
`Harper produced no startup output for 60000ms` — an integration-test `startHarper` call times out waiting for the child process's startup output, unrelated to the diff of whatever PR it appears on.
## Occurrences (2026-07-15, ~2.5hr window)
- `record-caching.test.ts` (harper#1808)
- `hot-record-read-snapshot.test.ts` (harper#1820)
- `record-caching TTL-eviction cross-worker ghost` (harper#1819)
- `bulk-conditional-mutation.test.ts` (harper#1819, again)
- a uWS HTTP shard on harper#1820, again
5 occurrences across 5 different test files/PRs in one morning, each confirmed unrelated to that PR's own diff.
## Investigation so far
- Checked githubstatus.com: all systems operational, no incidents.
- Checked `.github/workflows/` history: no CI workflow changes on the day(s) this cluster appeared.
- Checked `@harperfast/integration-testing`: harper's lockfile is pinned to 0.6.2; the newer 0.6.3 (published 2026-07-13) only touches the macOS loopback-alias setup script, not the Linux/Windows CI path or `startHarper`'s readiness signal — ruled out as the cause.
- No infra/dependency change found that correlates with the timing. This looks like genuine test-harness flakiness under load, not an environment regression.
## Leading theory
A `harper-1820-fix1` dispatch finding raised a plausible root cause: if `@harperfast/integration-testing`'s `startHarper` resolves before the HTTP listener is actually accepting connections (rather than after), that could explain both this startup-hang class and a separately observed `ECONNREFUSED`-on-first-request pattern from the same morning — one shared-helper fix candidate in the harness package itself.
## Also seen once
`unitTests/resources/crud.test.js:158` ("puts" — "db-write bytes count were recorded in analytics") flaked on harper#1820 — same analytics-flush-timing class previously fixed via harper#1794's `waitForAnalyticsMetric()` helper. This specific assertion may not be covered by that helper.
Contributor guide
Assessment
This issue has not been assessed yet.