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

オープン
  • 何か問題がありますか？
#5,041 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #5043 @yulman2207 による — マージされずにクローズ

評価

難易度
4/5
見積もり時間
1〜2日
初心者へのやさしさ
53/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
bun, docker, typescript
領域
build-system, infrastructure

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
16.5k
フォーク
1.5k
平均マージ
1日 15時間
マージ済み PR（30日）
17

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

triggerdotdev/trigger.dev のほかの issue

triggerdotdev/trigger.dev の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。