fix(webapp): use only per-query caps on the runs-list ClickHouse pool

Drops max_memory_usage_for_user and max_concurrent_queries_for_user. Those are
per-ClickHouse-user limits, and every connection is the default user, so hitting
the shared budget rejects whichever query arrives next rather than the one
responsible, which would fail queries for uninvolved tenants. The per-query caps
(max_execution_time, max_memory_usage, max_threads) bound a bad query to itself,
and the server-level max_server_memory_usage protects the node.

Author: ericallam

apps/webapp/app/env.server.ts

@@ -2237,8 +2237,6 @@ const EnvironmentSchema = z
     RUNS_LIST_CLICKHOUSE_MAX_EXECUTION_TIME: z.coerce.number().int().default(35),
     RUNS_LIST_CLICKHOUSE_MAX_THREADS: z.coerce.number().int().optional(),
     RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE: z.coerce.number().int().optional(),
-    RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE_FOR_USER: z.coerce.number().int().optional(),
-    RUNS_LIST_CLICKHOUSE_MAX_CONCURRENT_QUERIES_FOR_USER: z.coerce.number().int().optional(),
     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

@@ -293,11 +293,15 @@ function initializeRealtimeClickhouseClient(): ClickHouse {
 }
 
 /**
- * Server-side query protection for the runs-list read pool. Safe as client-level settings ONLY
- * because this pool is read-only (no inserts); a client-level `max_execution_time` on a mixed
- * read+write pool would also kill slow inserts. `readonly=2` enforces read-only while still
- * allowing these settings to apply (`readonly=1` rejects them). `max_concurrent_queries_for_user`
- * is a per-ClickHouse-user (`default`) fail-fast circuit breaker, not per-tenant isolation.
+ * Server-side query protection for the runs-list read pool. Every setting here is PER-QUERY, so a
+ * pathological query only ever kills itself: a slow one hits `max_execution_time`, a memory-hungry
+ * one hits `max_memory_usage`, a thread-hungry one hits `max_threads`. Per-USER limits
+ * (`max_*_for_user`) are deliberately NOT used: everything connects as `default`, so a per-user cap
+ * would reject whichever query arrives once the shared budget is hit, punishing innocent tenants
+ * for a noisy one. The node itself is protected by the server-level `max_server_memory_usage`.
+ * Safe as client-level settings ONLY because this pool is read-only; on a mixed read+write pool a
+ * 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).
  */
 function getRunsListClickhouseSettings(): ClickHouseSettings {
   const settings: ClickHouseSettings = {
@@ -314,14 +318,6 @@ function getRunsListClickhouseSettings(): ClickHouseSettings {
   if (env.RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE !== undefined) {
     settings.max_memory_usage = env.RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE.toString();
   }
-  if (env.RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE_FOR_USER !== undefined) {
-    settings.max_memory_usage_for_user =
-      env.RUNS_LIST_CLICKHOUSE_MAX_MEMORY_USAGE_FOR_USER.toString();
-  }
-  if (env.RUNS_LIST_CLICKHOUSE_MAX_CONCURRENT_QUERIES_FOR_USER !== undefined) {
-    settings.max_concurrent_queries_for_user =
-      env.RUNS_LIST_CLICKHOUSE_MAX_CONCURRENT_QUERIES_FOR_USER;
-  }
 
   return settings;
 }