bug: Old Bun 1.3.3 fetch aborts requests after 300 s idle

Abierto
  • ¿Algo no está bien?
#5,041 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

  • #5043 de @yulman2207 — cerrado sin fusionar

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
53/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
bun, docker, typescript
Área
build-system, infrastructure

Línea de trabajo

Start with packages/core/src/v3/schemas/build.ts to see how build runtime values are defined, then trace Bun image selection in packages/cli-v3/src/deploy/buildImage.ts and image names in base-images/images.json. Check how Node runtime versions are mapped as a guide. Done when a supported runtime can select a published Bun image and the deployment build uses it.

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

Descripción

Provide environment information

System:
OS: macOS 27.0.1
CPU: (10) arm64 Apple M2 Pro
Memory: 6.42 GB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.19.0 - /opt/homebrew/bin/node
npm: 11.17.0 - /opt/homebrew/bin/npm
bun: 1.4.3 - /Users/be/.bun/bin/bun

Deployed on Trigger.dev Cloud (prod, eu-central-1), trigger.dev CLI / @trigger.dev/sdk 4.6.3, trigger.config.ts runtime: "bun".
The local machine is not involved: the failure happens in the deployed image (Bun 1.3.3).

Describe the bug

runtime: "bun" always deploys on triggerdotdev/bun:1.3-node20-bookworm, which ships Bun 1.3.3. On Bun 1.3.x, fetch aborts any request that receives no bytes for 300 seconds, throwing TimeoutError: The operation timed out. A per-request timeout or AbortSignal longer than 300 s doesn't help.

Long, non-streaming LLM calls (for example Vertex AI generateContent with large structured outputs) send nothing until they finish, so on Trigger.dev they fail at exactly 5:00.

What we see:

  • A task on runtime: "bun" (trigger.dev 4.6.3) makes one AI SDK generateText call to Vertex AI with timeout: 360_000.
  • The run fails exactly 300 s after the call starts with TimeoutError: The operation timed out. That's Bun's message; Node's equivalent reads "The operation was aborted due to timeout".
  • The same request completes under Bun 1.4.x.

Expected: a supported way to run on a Bun release without this limit. You already publish triggerdotdev/bun:1.4-bookworm (Bun 1.4.2), but the CLI can't select it.

Reproduction repo

No repository needed: the reproduction is a single self-contained Bun script with no dependencies (see "To reproduce"). It runs a local server, so no network or Trigger.dev account is required.

To reproduce

Save as bun-timeout.ts and run bun run bun-timeout.ts with each Bun version. It takes about 5.5 minutes.

const server = Bun.serve({
  port: 0,
  idleTimeout: 0,
  fetch(req) {
    if (new URL(req.url).pathname === "/silent") {
      // headers and body only after 330 s
      return new Promise((resolve) => setTimeout(() => resolve(new Response("done")), 330_000));
    }
    // headers immediately, then one byte every 10 s for 330 s
    let n = 0;
    return new Response(
      new ReadableStream({
        async pull(controller) {
          await Bun.sleep(10_000);
          controller.enqueue(new TextEncoder().encode("."));
          if (++n >= 33) controller.close();
        },
      }),
    );
  },
});
const t0 = Date.now();
const run = async (path: string, init?: object) => {
  try {
    await (await fetch(`http://localhost:${server.port}${path}`, init)).text();
    console.log(Bun.version, path, JSON.stringify(init ?? {}), "ok after", (Date.now() - t0) / 1000, "s");
  } catch (e: any) {
    console.log(Bun.version, path, JSON.stringify(init ?? {}), "failed after", (Date.now() - t0) / 1000, "s:", e?.name, e?.message);
  }
};
await Promise.all([run("/silent"), run("/trickle"), run("/silent", { timeout: false })]);
server.stop(true);

Results with the official @oven/bun-darwin-aarch64 builds:

Bun silent 330 s trickle 330 s silent + timeout: false
1.3.3 (current runtime: "bun" image) failed at 300.0 s, TimeoutError: The operation timed out. ok ok
1.3.14 (bun:1.3-bookworm) failed at 300.0 s ok ok
1.4.2 (bun:1.4-bookworm) ok ok ok
1.4.3 ok ok ok

The limit is an idle timeout: the response that trickles a byte every 10 s survives.

In a deployed task, any fetch that waits more than 300 s for the first byte fails the same way.

Suggested fix

Make Bun 1.4 selectable, the same way Node majors are. For example runtime: "bun-1.4" (and "bun-1.3"), mapped to the already-published triggerdotdev/bun:1.4-bookworm / bun:1.3-bookworm images. Or move runtime: "bun" to a current Bun release.

Where the version comes from (checked on v4.7.4 and main as of 2026-10-20):

  • packages/core/src/v3/schemas/build.ts: BuildRuntime = z.enum(["node", "node-22", "node-24", "node-26", "bun"]), so there's no way to choose a Bun version.
  • packages/cli-v3/src/deploy/buildImage.ts: BASE_IMAGE.bun / BUILD_IMAGE.bun → triggerdotdev/bun:1.3-node20-bookworm(-build).
  • base-images/images.json: that image copies oven/bun:1.3.3-slim. The same file already publishes bun:1.3-bookworm (oven/bun:1.3.14-slim) and bun:1.4-bookworm (oven/bun:1.4.2-slim).

#5003 (build.image.base overrides) would allow a workaround, but a supported runtime value would keep projects on images you publish and test.

Additional information

Workaround: passing Bun's non-standard timeout: false to fetch removes the cap. But it has to reach every HTTP client a task uses (AI SDKs, Google auth), and it also removes the only bound for calls that set no timeout of their own.

In production, every failed run of one of certain tasks over two months died at exactly 300s on this error. Another task survived only because its retry happened to finish under 300s.

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.