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

The streamBatchItems suite was intermittently failing with a 30s test
timeout. The 30s budget covers container-fixture setup, and each of the
16 cases boots its own per-test Redis container and spins up a full
RunEngine; a cold container boot counts against the test's own timeout,
so under CI Docker contention whichever test booted while Docker was
busiest could exceed 30s. It is not a product-logic hang.

Two changes:

- Add a containerTestWithIsolatedRedisNoClickhouse fixture (Postgres
  template-clone + per-test Redis, no ClickHouse) and use it here. These
  tests never touch ClickHouse, yet the previous fixture's auto
  resetClickhouse forced a ClickHouse boot + full migration onto the
  cold-start test.
- Raise the suite testTimeout from 30s to 120s, matching the run-engine
  package convention for tests of this footprint (RunEngine + per-test
  container).

Author: d-cs

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

@@ -19,8 +19,9 @@ 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";
+// batch tests. The NoClickhouse variant skips the worker-scoped ClickHouse boot+migrate (these tests
+// never touch ClickHouse), which the cold-start test would otherwise pay inside its test timeout.
+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 +34,12 @@ import {
 } from "../../app/runEngine/services/streamBatchItems.server";
 import { ServiceValidationError } from "../../app/v3/services/baseService.server";
 
-vi.setConfig({ testTimeout: 30_000 }); // 30 seconds timeout
+// 120s (not 30s): each of the 16 cases here boots its own per-test Redis container and spins up a
+// full RunEngine, and a cold container boot counts against the test's own timeout. Under CI Docker
+// contention that boot can take tens of seconds, so 30s was too tight and the flake landed on
+// whichever test happened to boot while Docker was busiest. 120s matches the run-engine package
+// convention for tests of this footprint (RunEngine + per-test container).
+vi.setConfig({ testTimeout: 120_000 });
 
 describe("StreamBatchItemsService", () => {
   /**

internal-packages/testcontainers/src/index.ts

@@ -536,6 +536,28 @@ export const containerTestWithIsolatedRedis = test.extend<ContainerWithIsolatedR
   clickhouseClient: scopedClickhouseClient,
 });
 
+type ContainerWithIsolatedRedisNoClickhouseContext = {
+  network: StartedNetwork;
+  postgresContainer: StartedPostgreSqlContainer;
+  prisma: PrismaClient;
+  redisContainer: StartedRedisContainer;
+  redisOptions: RedisOptions;
+};
+
+// Postgres (template-clone) + per-test Redis, and NOTHING else. Same Redis isolation as
+// containerTestWithIsolatedRedis (for background work that outlives the test body) but without the
+// worker-scoped ClickHouse boot+migrate that the `resetClickhouse` auto fixture would otherwise force
+// on the first test in the file. Use this for tests that touch Postgres + Redis but never ClickHouse -
+// it removes the heaviest item from the cold-start container budget.
+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.