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

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.

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

• Schema without region / gates: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/routes/api.v1.runs.%24runParam.replay.ts#L25-L50
• Parse + cast: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/routes/api.v1.runs.%24runParam.replay.ts#L102-L116
• Service reads region: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/v3/services/replayTaskRun.server.ts#L107-L111
• Service reads gates: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/v3/services/replayTaskRun.server.ts#L153-L155
• Buffered snapshot includes gates, workerQueue, region: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/runEngine/services/triggerTask.server.ts#L981-L983
• SyntheticRun exposes region but has no gates: https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/v3/mollifier/readFallback.server.ts#L88 and https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/v3/mollifier/readFallback.server.ts#L227
• Dashboard path spreads SyntheticRun (keeps region, still no gates): https://github.com/triggerdotdev/trigger.dev/blob/93465d8549a735074d1ce7696bae3faebe577e8d/apps/webapp/app/v3/mollifier/syntheticReplayTaskRun.server.ts#L44

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.