Turbo Drive 2.0: Should a Global Timeout Configuration Be Added?

Short answer

A global timeout option is a reasonable addition, but only as a default with per-visit overrides, not as a single fixed value. The manual AbortController pattern works today and is the documented approach; the real question is whether centralizing it buys enough to justify new API surface and new semantics for cancellation events.

Confirmed facts vs. likely design

Confirmed: Turbo Drive's visits use the Fetch API, which has no built-in timeout. Without an AbortSignal, a request waits until the network stack or server terminates it. The current escape hatch is listening to turbo:before-fetch-request, creating an AbortController, and aborting from a setTimeout.

Likely, but not confirmed for any specific release: a built-in option would be implemented as a Turbo-owned AbortController, which means it must define precedence against user-supplied signals. Verify the exact event names and configuration surface against your installed @hotwired/turbo version before relying on them — they are version-sensitive.

Trade-offs of a global option

• Boilerplate removal is real but partial. A single default cannot fit heterogeneous endpoints — a fast index page and a slow CSV export need different limits. Any global value still needs per-visit overrides, so the simplification is smaller than it first appears.
• Signal conflicts. If Turbo owns a controller and a developer attaches another in turbo:before-fetch-request, you get double-abort or ambiguity. The API needs a documented rule: user signal wins, or signals are combined (any abort cancels).
• Event semantics. An aborted fetch surfaces as an AbortError. Today, cancellation via turbo:before-fetch-request means "don't send this request," which is different from "the request expired mid-flight." A built-in timeout should dispatch a distinguishable outcome so developers can tell user cancellation from timeout.
• Undefined UX. An aborted visit currently leaves the page unchanged. A built-in option must decide whether a timeout renders an error state, retries, or silently cancels — otherwise behavior diverges subtly from server-driven error responses.
• Server-side reality. Aborting the fetch does not stop server processing. A timed-out POST may still complete on the backend, so a low global timeout can cause users to resubmit non-idempotent forms.

Scoping recommendation

Global default plus per-visit override mirrors how Turbo already layers behavior: data-turbo-method and similar attributes override global config per element. A data-turbo-timeout attribute on links and forms, plus an option on Turbo.visit, fits the existing mental model. Frame-scoped timeouts add configuration complexity for marginal benefit — frames that need special handling can set the attribute on their own links and forms.

About the leak concern

Manual setups can leak timers if the timeout is not cleared when the fetch completes — that concern is legitimate. But it is not evidence a built-in option is leak-free; implementation quality still matters. If you stay with the manual pattern, clear the timer in a fetch completion handler, not just on abort.

Also worth checking: modern browsers ship AbortSignal.timeout(ms), which makes the manual pattern nearly trivial and reduces the pressure for a built-in option:

document.addEventListener("turbo:before-fetch-request", (event) => {
  event.detail.fetchOptions.signal = AbortSignal.timeout(10000);
});

Verify AbortSignal.timeout support against your target browsers before adopting it.

Bottom line

Yes, a global default timeout is defensible — but only with per-visit overrides, a documented signal-precedence rule, a distinct timeout event, and defined post-timeout UX. Without those four decisions, the option trades a small amount of boilerplate for ambiguous behavior. Prototype the manual pattern first and observe how your app handles a mid-flight abort (page state, progress bar, event sequence); that experiment defines what the built-in feature would actually need to do.