Bug: API replay of a mollifier-buffered run drops region and gates (BufferedReplayInputSchema strips them)

Abierto
  • ¿Algo no está bien?
#5,016 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Bhumit267 ya está trabajando en esto.

Desde el 21/10/2026.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
redis, typescript
Área
api, backend, testing

Línea de trabajo

Read apps/webapp/app/routes/api.v1.runs.$runParam.replay.ts and apps/webapp/app/v3/mollifier/readFallback.server.ts, then trace how ReplayTaskRunService uses region and gates. Check the existing replay tests for buffered runs and add coverage for preserving both fields through the API and dashboard paths. Done means buffered replay retains the stored region and named concurrency gates, matching replay from Postgres.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Replaying a run that is still in the mollifier buffer through POST /api/v1/runs/:runParam/replay loses the run's stored region and gates. The buffered snapshot goes through BufferedReplayInputSchema, a plain z.object that declares neither field, so Zod strips both before the result is cast to TaskRun and handed to ReplayTaskRunService. Separately, SyntheticRun has no gates field at all, so the dashboard replay of a buffered run loses gates too.

Reproduction

  1. Setup: webapp with the mollifier buffer enabled, and a task triggered with named concurrency gates while the environment is over the mollifier threshold, so the run sits in the buffer (the snapshot is built by #buildEngineTriggerInput and includes gates, workerQueue and region).
  2. Action: POST /api/v1/runs/<friendlyId>/replay while the run is still buffered.
  3. Trigger: the route reads the buffered entry with findRunByIdWithMollifierFallback, runs BufferedReplayInputSchema.safeParse(buffered) and then parsed.data as unknown as TaskRun. Every key the schema doesn't declare is dropped at that point.

Standalone repro of the parse step. The schema is copied verbatim from the route; the input is a SyntheticRun-shaped object as built by readFallback.server.ts:

import { z } from "zod";
const BufferedReplayInputSchema = z.object({
  id: z.string(), friendlyId: z.string(), runtimeEnvironmentId: z.string(), taskIdentifier: z.string(),
  payload: z.string(), payloadType: z.string(), queue: z.string(), isTest: z.boolean(),
  traceId: z.string(), spanId: z.string(), engine: z.string(), runTags: z.array(z.string()),
  concurrencyKey: z.string().nullable().optional(), workerQueue: z.string().nullable().optional(),
  machinePreset: z.string().nullable().optional(), realtimeStreamsVersion: z.string().nullable().optional(),
  seedMetadata: z.string().nullable().optional(), seedMetadataType: z.string().nullable().optional(),
});
const parsed = BufferedReplayInputSchema.parse({
  id: "run_1", friendlyId: "run_1", runtimeEnvironmentId: "env_1", taskIdentifier: "t",
  payload: "{}", payloadType: "application/json", queue: "task/t", isTest: false,
  traceId: "a".repeat(32), spanId: "b".repeat(16), engine: "V2", runTags: [],
  workerQueue: "us-east-1-base", region: "eu-central-1", gates: [{ queue: "g1" }],
});
console.log("region" in parsed, "gates" in parsed); // false false

I ran this with npx tsx from apps/webapp (zod 4.5.4).

Actual behavior

  • region and gates are missing from the object passed to ReplayTaskRunService.call.
  • The replay service computes overrideOptions.region || existingTaskRun.region || baseWorkerQueue(existingTaskRun.workerQueue), so it uses the worker-queue fallback instead of the stored region.
  • It passes gates: undefined, so the replayed run is created without the original run's named concurrency gates.
  • Once the drainer has written the same run to Postgres, replaying it does keep region and gates. Whether a replay keeps them therefore depends on whether the run happened to still be buffered.

Expected behavior

A buffered-source replay should carry the same fields as a PG-source replay. The route comment calls the schema a "Manual sync point" covering the fields ReplayTaskRunService consumes, and the service reads region and gates, which the schema doesn't include. Zod strips them silently, and the safeParse + 404 guard doesn't catch it because they are optional.

Environment

  • Version/commit: main @ 93465d8549a735074d1ce7696bae3faebe577e8d
  • OS: Ubuntu (Linux), Node v24.21.0
  • Relevant configuration: mollifier buffer enabled (run must still be buffered at replay time); the gates case needs a task/trigger with named concurrency gates

Evidence

Additional context

Confirmed from code and the standalone parse repro:

  • The API path drops region and gates.
  • Both buffered replay paths (API and dashboard) drop gates, because SyntheticRun never maps snapshot.gates.

Not verified end to end: I did not run a buffered replay against a live webapp with Redis.

Hypothesis about region impact: a visible difference needs the fallback baseWorkerQueue(workerQueue) to differ from the stored region. At trigger time region comes from regionForQueue, which returns the worker group's region label rather than its master-queue name, so the two can differ. I haven't checked how the downstream region resolution treats a master-queue name.

Possible fix: add region and gates to BufferedReplayInputSchema and map snapshot.gates onto SyntheticRun. Alternatively, derive the schema from SyntheticRun so the two can't drift apart again.

Found with an anti-slop oxlint scan (no-chained-type-assertions on the as unknown as TaskRun cast), then checked by hand.

Lenguaje dominante
TypeScript
Estrellas
16.5k
Forks
1.5k
Merge medio
1 d 15 h
PR fusionados (30 d)
17

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de triggerdotdev/trigger.dev

Todos los issues de triggerdotdev/trigger.dev

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.