test: honor SYNC_WAIT_MS in docker tests instead of clobbering it

tests/setup/per-fork-env.ts hardcoded SYNC_WAIT_MS=30000 on every fork, overriding whatever the container set, so the docker test image could never grant heavy ops a wider sync window. A 12MP stress-image enhance takes ~34s on the macOS Docker VM (Sharp runs 2-3x slower there), just past the 30s window, so the factory returned 202 and three sync-asserting image-enhancement tests failed.

Honor a higher SYNC_WAIT_MS when provided (30s floor preserved for host/CI), raise it to 120s in docker-compose.test.yml, and make the vitest test/hook timeouts env-overridable so a slow-but-correct job returns 200 rather than tripping a framework timeout. Host and CI behavior is unchanged.
This commit is contained in:
SnapOtter
2026-06-17 14:28:41 +08:00
parent 1f5b222267
commit 63a2d309ce
3 changed files with 23 additions and 7 deletions
+8 -2
View File
@@ -24,8 +24,14 @@ process.env.REDIS_URL = redisBaseUrl;
process.env.BULLMQ_PREFIX = `snapotter_test_${suffix}`;
// Heavy format conversions can exceed the 8s production default under parallel
// test forks; 30s keeps tool routes synchronous (200) in tests while production stays at 8s.
process.env.SYNC_WAIT_MS = "30000";
// test forks; 30s keeps tool routes synchronous (200) in tests while production
// stays at 8s. The constrained docker test image (macOS Docker VM, where Sharp
// and FFmpeg run ~2-3x slower) can request a larger window via SYNC_WAIT_MS;
// honor it rather than clobbering, but never drop below the 30s test floor.
const requestedSyncWait = Number(process.env.SYNC_WAIT_MS);
process.env.SYNC_WAIT_MS = String(
Number.isFinite(requestedSyncWait) && requestedSyncWait > 30000 ? requestedSyncWait : 30000,
);
const dbName = `snapotter_test_${suffix}`; // pid digits + uuid hex: identifier-safe
const admin = new pg.Client({ connectionString: baseUrl });
await admin.connect();