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

Ouverte
  • Quelque chose ne va pas ?
#5,016 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@Bhumit267 y travaille déjà.

Depuis le 21/10/2026.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
redis, typescript
Domaine
api, backend, testing

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
16.5k
Forks
1.5k
Merge moyen
1 j 15 h
PR mergées (30 j)
17

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de triggerdotdev/trigger.dev

Toutes les issues de triggerdotdev/trigger.dev

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.