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

Aberta
  • Algo errado?
#5,016 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@Bhumit267 já está trabalhando nisso.

Desde 21/10/2026.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
72/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
redis, typescript
Domínio
api, backend, testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
16.5k
Forks
1.5k
Merge médio
1d 15h
PRs com merge (30d)
17

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de triggerdotdev/trigger.dev

Todas as issues de triggerdotdev/trigger.dev

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.