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

Offen
  • Stimmt etwas nicht?
#5,016 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Bhumit267 arbeitet bereits daran.

Seit 21.10.2026.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
redis, typescript
Bereich
api, backend, testing

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
16.5k
Forks
1.5k
Ø Merge
1 T. 15 Std.
Gemergte PRs (30 T.)
17

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus triggerdotdev/trigger.dev

Alle Issues in triggerdotdev/trigger.dev

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.