fix(webapp): harden runs-list pool timeout and cap validation

Client request timeout now sits above the server max_execution_time (default
40s vs 35s, and the factory forces it to at least exec + 5s), so the server-side
cap is what stops a slow query and the client stays connected to receive the
error, instead of aborting first and leaving the query running. The numeric caps
reject zero and negative values, since ClickHouse treats 0 as unlimited for
max_execution_time and max_memory_usage, which would silently disable them.

Author: ericallam

apps/webapp/app/env.server.ts

@@ -2233,10 +2233,14 @@ const EnvironmentSchema = z
       .enum(["log", "error", "warn", "info", "debug"])
       .default("info"),
     RUNS_LIST_CLICKHOUSE_COMPRESSION_REQUEST: z.string().default("1"),
-    RUNS_LIST_CLICKHOUSE_REQUEST_TIMEOUT_MS: z.coerce.number().int().default(30_000),
-    RUNS_LIST_CLICKHOUSE_MAX_EXECUTION_TIME: z.coerce.number().int().default(35),
-    RUNS_LIST_CLICKHOUSE_MAX_THREADS: z.coerce.number().int().default(4),
-    RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE: z.coerce.number().int().default(1_073_741_824),
+    RUNS_LIST_CLICKHOUSE_REQUEST_TIMEOUT_MS: z.coerce.number().int().positive().default(40_000),
+    RUNS_LIST_CLICKHOUSE_MAX_EXECUTION_TIME: z.coerce.number().int().positive().default(35),
+    RUNS_LIST_CLICKHOUSE_MAX_THREADS: z.coerce.number().int().positive().default(4),
+    RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE: z.coerce
+      .number()
+      .int()
+      .positive()
+      .default(1_073_741_824),
     RUNS_LIST_CLICKHOUSE_READONLY: z.enum(["0", "1", "2"]).default("2"),
     /**
      * Dedicated ClickHouse service for queue metrics: the ingestion consumer's inserts and every

apps/webapp/app/services/clickhouse/clickhouseFactory.server.ts

@@ -303,6 +303,19 @@ function initializeRealtimeClickhouseClient(): ClickHouse {
  * client-level `max_execution_time` would also kill slow inserts. `readonly=2` enforces read-only
  * while still allowing these settings to apply (`readonly=1` rejects them).
  */
+/**
+ * Client request timeout for the runs-list pool, forced above the server-side `max_execution_time`
+ * so the server cap is what stops a slow query and the client stays connected to receive that
+ * error. If the client timed out first, it would abort while ClickHouse kept executing, which is
+ * the abandoned-query behaviour this pool is trying to prevent.
+ */
+function getRunsListRequestTimeoutMs() {
+  return Math.max(
+    env.RUNS_LIST_CLICKHOUSE_REQUEST_TIMEOUT_MS,
+    (env.RUNS_LIST_CLICKHOUSE_MAX_EXECUTION_TIME + 5) * 1000
+  );
+}
+
 function getRunsListClickhouseSettings(): ClickHouseSettings {
   const settings: ClickHouseSettings = {
     max_execution_time: env.RUNS_LIST_CLICKHOUSE_MAX_EXECUTION_TIME,
@@ -345,7 +358,7 @@ function initializeRunsListClickhouseClient(): ClickHouse {
       request: env.RUNS_LIST_CLICKHOUSE_COMPRESSION_REQUEST === "1",
     },
     maxOpenConnections: env.RUNS_LIST_CLICKHOUSE_MAX_OPEN_CONNECTIONS,
-    requestTimeoutMs: env.RUNS_LIST_CLICKHOUSE_REQUEST_TIMEOUT_MS,
+    requestTimeoutMs: getRunsListRequestTimeoutMs(),
     clickhouseSettings: getRunsListClickhouseSettings(),
   });
 }
@@ -591,7 +604,7 @@ function buildOrgClickhouseClient(url: string, clientType: ClientType): ClickHou
           request: env.RUNS_LIST_CLICKHOUSE_COMPRESSION_REQUEST === "1",
         },
         maxOpenConnections: env.RUNS_LIST_CLICKHOUSE_MAX_OPEN_CONNECTIONS,
-        requestTimeoutMs: env.RUNS_LIST_CLICKHOUSE_REQUEST_TIMEOUT_MS,
+        requestTimeoutMs: getRunsListRequestTimeoutMs(),
         clickhouseSettings: getRunsListClickhouseSettings(),
       });
     case "standard":