fix(ci): cap integration-test parallelism to dodge sqlx-test pool timeout #115

Merged

nrupard merged 1 commit from fix/check-pg-pool-saturation into main

2026-06-05 20:52:21 +02:00

nrupard commented

2026-06-05 20:48:45 +02:00

Owner

Summary

Two consecutive check.yml runs flaked with failed to connect test pool: PoolTimedOut on tests/auth.rs. Same two tests both times:

forgot_password_with_tenant_hint_targets_correct_user
list_users_requires_admin

12 of 14 tests in the binary pass; the failures are at sqlx-test's per-test-database creation step, not the test logic itself.

Root cause

tests/auth.rs has 14 #[sqlx::test] functions. cargo defaults to per-cpu in-flight (16+ on the runner). Each test creates a per-test database AND borrows from sqlx-test's maintenance pool that creates/drops those databases. At default parallelism the maintenance pool was timing out under contention.

Fix

Cap concurrency with cargo test ... -- --test-threads=4. Four in-flight is well within postgres's default max_connections=100 and leaves headroom for adding modules. Trade-off: small wall-clock cost, full reliability.

Alternative considered: bump postgres max_connections to 300. Rejected because Forgejo Actions service blocks don't expose a command field to pass -c max_connections=... to the postgres image, and going via POSTGRES_INITDB_ARGS only affects initdb-time settings, not runtime config.

Test plan

CI green on this PR.
Re-run the integration-test step a couple of times to confirm the flake doesn't recur under the new cap.

## Summary Two consecutive `check.yml` runs flaked with `failed to connect test pool: PoolTimedOut` on `tests/auth.rs`. Same two tests both times: - `forgot_password_with_tenant_hint_targets_correct_user` - `list_users_requires_admin` 12 of 14 tests in the binary pass; the failures are at sqlx-test's per-test-database creation step, not the test logic itself. ## Root cause `tests/auth.rs` has 14 `#[sqlx::test]` functions. cargo defaults to per-cpu in-flight (16+ on the runner). Each test creates a per-test database AND borrows from sqlx-test's maintenance pool that creates/drops those databases. At default parallelism the maintenance pool was timing out under contention. ## Fix Cap concurrency with `cargo test ... -- --test-threads=4`. Four in-flight is well within postgres's default `max_connections=100` and leaves headroom for adding modules. Trade-off: small wall-clock cost, full reliability. Alternative considered: bump postgres `max_connections` to 300. Rejected because Forgejo Actions service blocks don't expose a `command` field to pass `-c max_connections=...` to the postgres image, and going via `POSTGRES_INITDB_ARGS` only affects initdb-time settings, not runtime config. ## Test plan - [ ] CI green on this PR. - [ ] Re-run the integration-test step a couple of times to confirm the flake doesn't recur under the new cap.

nrupard added 1 commit

2026-06-05 20:48:45 +02:00

fix(ci): cap integration-test parallelism to dodge sqlx-test pool timeout

E2E (staging) / Playwright against staging (pull_request) Successful in 32s

Details

Check / fmt + clippy + compile + tests (pull_request) Successful in 1m33s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

eea87f35d5

`tests/auth.rs` flaked twice with `failed to connect test pool: PoolTimedOut` on `forgot_password_with_tenant_hint_targets_correct_user` and `list_users_requires_admin`. Same binary has 14 `#[sqlx::test]` functions; cargo defaults to per-cpu in-flight (16+ on the runner). Each test creates a per-test database AND borrows from sqlx-test's maintenance pool that creates/drops databases. At default parallelism the maintenance pool was timing out under contention.

Cap concurrency with `cargo test ... -- --test-threads=4`. Four in-flight is well within postgres's default `max_connections=100` and leaves headroom for adding modules; the wall-clock cost is small compared to the time spent debugging a flake.

A `max_connections=300` bump on the postgres service would also work but Forgejo Actions service blocks don't expose a `command` field to pass `-c max_connections=...`, so the test-threads cap is the cleaner lever here.