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.

docker/docker-compose.test.yml

@@ -25,9 +25,16 @@ services:
       - WORKSPACE_PATH=/tmp/test-workspace
       - MAX_MEGAPIXELS=100
       - RATE_LIMIT_PER_MIN=1000
-      # Single constrained container; give sync-wait tools more headroom before
+      # The macOS Docker VM runs Sharp/FFmpeg ~2-3x slower than the host and
-      # the factory falls back to async 202 (default is 8s).
+      # oversubscribes CPU across parallel vitest forks, so heavy ops (e.g. a
-      - SYNC_WAIT_MS=30000
+      # 12MP stress-image enhance) blow past the 30s test sync window and fall
+      # back to a 202 that sync-asserting tests reject. Give the sync window
+      # generous headroom (honored by tests/setup/per-fork-env.ts) and keep the
+      # framework test/hook timeouts above it so a slow-but-correct job returns
+      # 200 instead of tripping a vitest timeout. Host/CI keep the 30s defaults.
+      - SYNC_WAIT_MS=120000
+      - VITEST_TEST_TIMEOUT=180000
+      - VITEST_HOOK_TIMEOUT=120000
     tmpfs:
       - /tmp/test-workspace
       - /tmp

tests/setup/per-fork-env.ts

@@ -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.
+// test forks; 30s keeps tool routes synchronous (200) in tests while production
-process.env.SYNC_WAIT_MS = "30000";
+// 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();

vitest.config.ts

@@ -32,8 +32,11 @@ export default defineConfig({
   },
   test: {
     globals: true,
-    testTimeout: 30_000,
+    // Env-overridable so the resource-constrained docker test image (where Sharp
-    hookTimeout: 30_000,
+    // and FFmpeg run ~2-3x slower under the macOS Docker VM) can grant slow
+    // sync-wait jobs more headroom. Host/CI keep the 30s default.
+    testTimeout: Number(process.env.VITEST_TEST_TIMEOUT) || 30_000,
+    hookTimeout: Number(process.env.VITEST_HOOK_TIMEOUT) || 30_000,
     pool: "forks",
     poolOptions: {
       forks: {