feat(middleware): allow overriding timeout in subroutes

[ismailkarsli]

This PR allows users to override upstream route timeouts. This enables users to set a general, application-wide timeout while configuring specific exceptions for long-running routes.

Key Changes

• Uses context.get/set to store timeoutTimer, ensuring any existing timer is cleared before a new one is created.
• Updates the middleware handler type to include Variables.timeoutTimer.
• Adds a test route and assertions to verify that the previous timeout is successfully overridden.

Questions/comments

• I'm not sure about exposing the timer with variables. It allows users manipulate it but at the same time it can pollute variable space. Do I need to change it to an internal namespace?
• Do I need to fetch timeoutTimer from variables after next() function?

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.85%. Comparing base (0bce36b) to head (1531c54).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4853   +/-   ##
=======================================
  Coverage   92.85%   92.85%           
=======================================
  Files         177      177           
  Lines       11657    11662    +5     
  Branches     3474     3475    +1     
=======================================
+ Hits        10824    10829    +5     
  Misses        832      832           
  Partials        1        1           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[yusukebe]

Hey @ismailkarsli

Thank you for the PR. I can understand what you want to do in rough terms, but can you provide use cases for this feature? What is the situation in which the user wants to modify the timer?

[ismailkarsli]

Hello, thanks for the consideration @yusukebe.

For my use case, I wanted to add a generic timeout to all routes. For example, a safe timeout of 30 seconds for CRUD operations.

However, sometimes a deeply nested route might need to take a long time, and an exception might be required only for that route, as in the example below.

const app = new Hono();
app.use(timeout(30000)); // Set a generic timeout for all routes

app.use("/slightly-slow-route", timeout(60000), async (c, next) => {
	await someLongRunningFunction();
	return c.text("Completed within 60 seconds");
});

const user = new Hono();
app.use("/user", user);
// Allow up to 2 minutes for user export in a nested route.
user.get("/export", timeout(120000), async (c) => {
	await someLongRunningFunction();
	return c.text("Completed within 120 seconds");
});

So I don't want to sacrifice the convenience of app.use(timeout(30000)) to create an exception only for a specific route. Therefore, I added the existing timeout timer to the context so that it can be removed/modified in a future middleware.

To be honest, I don't particularly like the timeout timer being shared in the context, but I'm not sure if there's another way to share variables with next middlewares.