`src/read.test.ts`'s AES-256 decryption tests (15000ms timeout) and `src/math-stretch.test.ts`'s STIX Two Math glyph-naming test (30000ms timeout) intermittently exceed their own explicit timeouts when the CI `Test` job runs the full `--affected` matrix under contention -- confirmed reproducing on `main` independent of any pdf-codec change (commit c661f04, run https://github.com/ExaDev/documents.js/actions/runs/33962730052/job/101297704453), and reproduced twice more on an unrelated document-schema.js PR (#999, https://github.com/ExaDev/documents.js/actions/runs/33964128795, both the original run and an immediate rerun with no code change).
`src/read.test.ts` already documents the underlying cause in a comment above the fixtures table: AES-256's key derivation runs the SHA-256/384/512 hardened hash of ISO 32000-2 Algorithm 2.B, CPU-bound and slow enough under load to miss vitest's default 5000ms timeout -- which is why it's already been bumped to 15000ms. That bump isn't enough when `document-schema.js` or another foundation package changes, since the `--affected` matrix then pulls in most of the workspace's own test suites running concurrently on one shared runner, and 15s/30s no longer holds under that contention.
Failing every time it's been observed with the exact same two files: `src/math-stretch.test.ts` ("names glyphs that no Unicode code point reaches...") and `src/read.test.ts` (both AES-256 decrypt fixtures). Not a transient one-in-N flake so much as a hard-coded timeout that stops being sufficient once the runner is busy with a large affected set.
Worth one of: raising both timeouts further, isolating these two CPU-bound suites into their own vitest `pool`/thread so they don't contend with the rest of the affected matrix, or excluding them from `--affected` fan-out and running them in a dedicated, less contended job.
`src/read.test.ts`'s AES-256 decryption tests (15000ms timeout) and `src/math-stretch.test.ts`'s STIX Two Math glyph-naming test (30000ms timeout) intermittently exceed their own explicit timeouts when the CI `Test` job runs the full `--affected` matrix under contention -- confirmed reproducing on `main` independent of any pdf-codec change (commit c661f04, run https://github.com/ExaDev/documents.js/actions/runs/33962730052/job/101297704453), and reproduced twice more on an unrelated document-schema.js PR (#999, https://github.com/ExaDev/documents.js/actions/runs/33964128795, both the original run and an immediate rerun with no code change).
`src/read.test.ts` already documents the underlying cause in a comment above the fixtures table: AES-256's key derivation runs the SHA-256/384/512 hardened hash of ISO 32000-2 Algorithm 2.B, CPU-bound and slow enough under load to miss vitest's default 5000ms timeout -- which is why it's already been bumped to 15000ms. That bump isn't enough when `document-schema.js` or another foundation package changes, since the `--affected` matrix then pulls in most of the workspace's own test suites running concurrently on one shared runner, and 15s/30s no longer holds under that contention.
Failing every time it's been observed with the exact same two files: `src/math-stretch.test.ts` ("names glyphs that no Unicode code point reaches...") and `src/read.test.ts` (both AES-256 decrypt fixtures). Not a transient one-in-N flake so much as a hard-coded timeout that stops being sufficient once the runner is busy with a large affected set.
Worth one of: raising both timeouts further, isolating these two CPU-bound suites into their own vitest `pool`/thread so they don't contend with the rest of the affected matrix, or excluding them from `--affected` fan-out and running them in a dedicated, less contended job.