timescale.info#279 · The document stream test can no longer hang on a failed check
- timeline-app
- pull request
Closes #238. **Cause.** At the end, `test/document-stream-postgres.mjs` checks that an open stream holds one connection and gives it back, by counting the pool's busy clients. The saves and creates earlier in the test schedule catalogue text refreshes (`refreshText`, after a 1 s delay), and those borrow clients from the same pool. When the check runs, two refreshes are typically still running, so the count can change between readings. - If the second check ("gives it back") fails, the test fails normally. Reproduced once in 8 sequential runs of the old test under CPU load. - If the first check ("holds a connection") fails, the stream it measures is still open. `pool.end()` in the `finally` then waits on that connection forever, and the assertion error is never printed. Forcing that check to fail with the old cleanup hung silently until it was killed (exit 124), which is the CI symptom. No server code was at fault. `inSnapshot` releases its client on completion, failure and early `return()`, and the refused generators reject before they hold anything. **Fix (test only).** - Wait for `store.idle()` before counting connections. - Close any stream a failed check may leave open (`refused`, `early`) before cleanup, so a failure is reported instead of hanging. **Checked.** - 14 of 14 sequential runs pass under CPU load. - A forced failure now prints its assertion and exits after about 40 s. - `npm test` passes. - `npm run test:platform:postgres` passes. Its first run hit an unrelated flake at `test/next-postgres.mjs:357`: the fork's `/document` returned 200 instead of 409 while it was marked preparing. The rerun passed. Running several copies of the test in parallel against one database deadlocks while applying `schema.sql`. CI runs them one after another, so that doesn't happen there.
Sources
Open #279 · The document stream test can no longer hang on a failed check in the timeline