next build can wait far beyond the built-in telemetry timeout when a caller signal is provided

Link to the code that reproduces this issue

https://github.com/cyhforlight/next-telemetry-timeout-repro

To Reproduce

1. Clone the reproduction repository:

git clone https://github.com/cyhforlight/next-telemetry-timeout-repro.git
cd next-telemetry-timeout-repro

2. Build the Docker image:

docker build -t next-telemetry-timeout-repro .

3. Run the reproduction:

docker run --rm \
  --add-host telemetry.nextjs.org:127.0.0.1 \
  next-telemetry-timeout-repro

4. Observe that the telemetry-disabled build finishes normally, while the telemetry-enabled build takes significantly longer than the built-in five-second timeout.

The script prints BUG REPRODUCED and exits with code 0 when the telemetry-attributable delay exceeds the eight-second reproduction threshold.

Current vs. Expected behavior

Current behavior

The same unmodified project is built twice in the same container, with .next removed between runs. The only relevant difference is whether NEXT_TELEMETRY_DISABLED=1 is set.

With Next.js 16.2.6:

telemetry disabled: 2.2s (exit 0)
telemetry enabled:  23.4s (exit 0)
attributable to telemetry: 21.2s

The telemetry request's built-in five-second timeout is not installed when the caller provides a signal. The production build path passes postController.signal, so a stalled request falls back to the HTTP client's substantially longer timeouts.

Expected behavior

The caller-provided cancellation signal should not replace the telemetry request timeout. A stalled telemetry endpoint should stop delaying next build after approximately five seconds, while caller-initiated cancellation should continue to work.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Fri Jun 5 01:12:21 UTC 2026
  Available memory (MB): 15746
  Available CPU cores: 16
Binaries:
  Node: 20.20.2
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 16.3.0-canary.97
  eslint-config-next: N/A
  react: 19.2.0
  react-dom: 19.2.0
  typescript: N/A
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Runtime, Performance

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

I originally encountered this while running next build behind a TUN/Fake-IP proxy, where the telemetry connection stopped making progress. The reproduction removes the proxy dependency and replaces it with a deterministic local TCP endpoint.

I also tested the same reproduction against next@16.3.0-canary.97 without changing or instrumenting the Next.js runtime:

telemetry disabled: 3.0s (exit 0)
telemetry enabled:  45.1s (exit 0)
attributable to telemetry: 42.2s

The relevant condition is still present on canary:

https://github.com/vercel/next.js/blob/canary/packages/next/src/telemetry/post-telemetry-payload.ts

A related report previously described telemetry.flush() waiting indefinitely, but maintainers could not reproduce it consistently:

https://github.com/vercel/next.js/discussions/71063

This repository provides a deterministic reproduction and an A/B comparison with telemetry disabled.

I opened #96327 with a candidate fix and regression tests.

Start with packages/next/src/telemetry/post-telemetry-payload.ts and run the linked Docker reproduction to compare telemetry-enabled and disabled builds. Review the candidate fix and regression tests in #96327. Done means a stalled telemetry endpoint no longer delays next build beyond roughly five seconds while caller cancellation still works.