test(user): the published-passwords spec carries its own timeout for its real hashing
What
user.service.published-passwords.spec.ts now states its own budget, jest.setTimeout(30_000). The real hashing stays.
Why
The spec hashes and verifies passwords for real, deliberately: scrypt and bcrypt at production cost. What it covers is a boot-time security check (GHSA-4r2r-mv32-3468), so faking the hashing would hollow it out. That work is CPU-bound. The slowest test takes about 1.2 s alone, and on 10-15 it crossed jest's 5 s default when the file ran beside other suites on a 4-CPU host:
FAIL core packages/core/src/lib/user/user.service.published-passwords.spec.ts (18.621 s)
● UserService.findAccountsUsingPasswords › reports an account whose stored hash still verifies against its published password
thrown: "Exceeded timeout of 5000 ms for a test.
The file took 18.6 s against about 4.8 s alone, and passed 13/13 when re-run by itself. The budget belongs to the test, not to the product: the check runs once per start.
Red first, deterministically
A timing flake has no deterministic red, so I didn't flood the shared build host with CPU hogs. Instead, jest's default is lowered to stand in for load against the budget:
--testTimeout=300 | plain | |
|---|---|---|
| develop's file | 4 / 13 fail, "Exceeded timeout of 300 ms" (the 10-15 failure) | 13 / 13 |
| this PR | 13 / 13 (the file's own 30 s budget applies) | 13 / 13 |
The 30 static gates pass.
Spec-only change: nothing in the product changes.
🤖 Generated with Claude Code
Summary by cubic
Gives user.service.published-passwords.spec.ts its own 30-second timeout because its deliberately real scrypt and bcrypt hashing is CPU-bound and tripped Jest's 5-second default when the file ran alongside other suites on a 4-CPU host (a flake that failed with "Exceeded timeout of 5000 ms" but passed 13/13 when re-run alone).
The hashing stays real — it covers a boot-time security check (GHSA-4r2r-mv32-3468) — and the budget belongs to the test, not to the product path, which runs the check once per start. Verified deterministically by lowering Jest's default to 300 ms to stand in for load: develop's file fails 4/13, this file passes 13/13. Spec-only change, no product behavior changes.