test(webapp): stop streamBatchItems container tests timing out on cold start (#3900)

Fixes an intermittent `Test timed out in 30000ms` in the
`streamBatchItems` suite. Not a logic hang — the 30s budget covers
container setup, and each case boots its own per-test Redis container +
a full `RunEngine`, so under CI Docker contention a cold boot can cross
30s (which is why the failure moved between tests).

- New `containerTestWithIsolatedRedisNoClickhouse` fixture (Postgres
clone + per-test Redis, no ClickHouse) — this suite never uses
ClickHouse, but the old fixture's auto `resetClickhouse` forced a
ClickHouse boot + migration onto the cold-start test.
- Raised `testTimeout` 30s → 120s, matching the run-engine convention
for this footprint.

Author: d-cs

apps/webapp/test/engine/streamBatchItems.test.ts

@@ -16,11 +16,9 @@ vi.mock("~/services/platform.v3.server", async (importOriginal) => {
 
 import { RunEngine } from "@internal/run-engine";
 import { setupAuthenticatedEnvironment } from "@internal/run-engine/tests";
-// Per-test redis (isolated): each test spins up its own RunEngine and runs batch work, which leaves
-// background activity on redis that outlives the test - sharing a worker redis across the 16 cases
-// here caused cross-test interference and 30s seal-timeout flakes. Same carve-out as the run-engine
-// batch tests.
-import { containerTestWithIsolatedRedis as containerTest } from "@internal/testcontainers";
+// Per-test redis isolation: each test runs its own RunEngine whose background work outlives the test
+// body. NoClickhouse because this suite never touches ClickHouse - skips the worker-scoped boot+migrate.
+import { containerTestWithIsolatedRedisNoClickhouse as containerTest } from "@internal/testcontainers";
 import { trace } from "@opentelemetry/api";
 import { PrismaClient } from "@trigger.dev/database";
 import { BatchId } from "@trigger.dev/core/v3/isomorphic";
@@ -33,7 +31,9 @@ import {
 } from "../../app/runEngine/services/streamBatchItems.server";
 import { ServiceValidationError } from "../../app/v3/services/baseService.server";
 
-vi.setConfig({ testTimeout: 30_000 }); // 30 seconds timeout
+// 120s: a cold per-test container boot counts against the test's own timeout, and under CI Docker
+// contention 30s was too tight. Matches the run-engine convention for this footprint.
+vi.setConfig({ testTimeout: 120_000 });
 
 describe("StreamBatchItemsService", () => {
   /**

internal-packages/testcontainers/src/index.ts

@@ -536,6 +536,25 @@ export const containerTestWithIsolatedRedis = test.extend<ContainerWithIsolatedR
   clickhouseClient: scopedClickhouseClient,
 });
 
+type ContainerWithIsolatedRedisNoClickhouseContext = {
+  network: StartedNetwork;
+  postgresContainer: StartedPostgreSqlContainer;
+  prisma: PrismaClient;
+  redisContainer: StartedRedisContainer;
+  redisOptions: RedisOptions;
+};
+
+// Like containerTestWithIsolatedRedis (template-clone Postgres + per-test Redis) but with no
+// ClickHouse - for suites that touch Postgres + Redis but never ClickHouse, avoiding its boot+migrate.
+export const containerTestWithIsolatedRedisNoClickhouse =
+  test.extend<ContainerWithIsolatedRedisNoClickhouseContext>({
+    network,
+    postgresContainer: clonedPostgresContainer,
+    prisma: prismaFromContainer,
+    redisContainer,
+    redisOptions,
+  });
+
 // For tests that exercise the Postgres -> ClickHouse logical-replication pipeline (WAL slots,
 // publications, REPLICA IDENTITY). These need a dedicated Postgres per test - the worker-scoped +
 // template-clone model used by containerTest doesn't carry logical replication across cloned dbs.