fix(webapp): strip only a poison run's output, not its error

Recovery emptied both `output` and `error` on the un-ingestable row while
keeping `error_fingerprint`, so a stripped failed run still matched the error
materialized views with no error content left. Those views pick their display
columns with `any()` over the fingerprint group, so a single stripped run could
retitle every run sharing that fingerprint to a generic type and message.

In practice the un-ingestable JSON is the run's output, so the strip now touches
only that column and leaves `error` and its fingerprint consistent with each
other. A run whose error is itself un-ingestable no longer makes progress from
the strip and is skipped by the allow_errors bail instead of landing without the
error content its fingerprint promises.

Author: ericallam

apps/webapp/app/services/runsReplicationService.server.ts

@@ -205,8 +205,9 @@ export class RunsReplicationService {
   private _recoveryCapHits = 0;
 
   /**
-   * Counts rows that landed with their un-ingestable JSON column(s) stripped
-   * (the run kept its status, only the output/payload content was lost).
+   * Counts rows that landed with their un-ingestable `output` emptied (the run
+   * kept its status, only the output content was lost; it still reads from
+   * Postgres on the run detail page).
    */
   private _rowsStripped = 0;
 
@@ -1603,9 +1604,18 @@ function landedRowCount(groupSize: number, outcome: JsonParseRecoveryOutcome): n
 
 const STRIPPED_JSON: { data: unknown } = { data: undefined };
 
+/**
+ * Empties `output`, the run JSON that in practice exceeds what ClickHouse can
+ * ingest (a large or deeply nested task return value). `error` is deliberately
+ * left alone: emptying it while keeping `error_fingerprint` would let the row
+ * match the error materialized views with no error content, and since those
+ * views pick their display columns with `any()` over the fingerprint group, one
+ * stripped run could retitle every run sharing that fingerprint. A run whose
+ * `error` is itself un-ingestable therefore makes no progress here and falls
+ * through to the `allow_errors` bail, which skips just that row.
+ */
 function stripTaskRunJsonColumns(row: TaskRunInsertArray): TaskRunInsertArray {
   const stripped = [...row] as TaskRunInsertArray;
   stripped[TASK_RUN_INDEX.output] = STRIPPED_JSON;
-  stripped[TASK_RUN_INDEX.error] = STRIPPED_JSON;
   return stripped;
 }

apps/webapp/app/v3/eventRepository/sanitizeRowsOnParseError.server.ts

@@ -232,10 +232,12 @@ export const DEFAULT_MAX_POISON_STRIPS = 1;
  *   2. On a parse error, `sanitizeRows` losslessly repairs what it can in place
  *      (lone UTF-16 surrogates, out-of-range integers) and retries once.
  *   3. If the sanitizer can't help, follow ClickHouse's `at row N` hint to the
- *      un-ingestable row and re-insert with that row's JSON column(s) emptied
- *      via `stripJsonColumns`, up to `maxPoisonStrips` rows. Each stripped run
- *      still lands (keeps its terminal status); only its un-ingestable JSON is
- *      lost. `insertSync` disables parallel parsing so `at row N` is reliable.
+ *      un-ingestable row and re-insert with the caller-selected JSON column(s)
+ *      emptied via `stripJsonColumns`, up to `maxPoisonStrips` rows. Each
+ *      stripped run still lands (keeps its terminal status); only the emptied
+ *      content is lost. A row the caller's strip cannot make ingestable is
+ *      reported again, makes no progress, and falls through to step 4.
+ *      `insertSync` disables parallel parsing so `at row N` is reliable.
  *   4. Cost bound: once `maxPoisonStrips` rows have been stripped and the batch
  *      STILL fails (or the failing row can't be located), stop stripping and
  *      land the batch with one `allow_errors` insert — the stripped rows and