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

Offen
  • Stimmt etwas nicht?
#5,041 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

  • #5043 von @yulman2207 — ohne Merge geschlossen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
53/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
bun, docker, typescript
Bereich
build-system, infrastructure

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

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.