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

Aberta
  • Algo errado?
#5,041 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

  • #5043 de @yulman2207 — fechado sem integrar

Avaliação

Dificuldade
4/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
53/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
bun, docker, typescript
Domínio
build-system, infrastructure

Direção de pesquisa

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.

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

Descrição

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.

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.