🩹 fix: Timeout middleware not enforced

[edvardsanta]

Description

This PR refactors the timeout middleware to properly enforce request timeouts by:

1. Wrapping the handler execution in a goroutine.
   2 Using a select statement to handle three possible outcomes:

   • Handler completes successfully.
   • Handler panics (panic is propagated).
   • Timeout occurs, triggering cfg.OnTimeout if set, or returning fiber.ErrRequestTimeout..

This change guarantees that:

• The timeout is respected in real time.
• Handlers have the opportunity to observe context cancellation if needed.
• Panics are safely propagated without losing stack traces.

Fixes #3671

Changes introduced

List the new features or adjustments introduced in this pull request. Provide details on benchmarks, documentation updates, changelog entries, and if applicable, the migration guide.

• Benchmarks: Describe any performance benchmarks and improvements related to the changes.
• Documentation Update: Detail the updates made to the documentation and links to the changed files.
• Changelog/What's New: Include a summary of the additions for the upcoming release notes.
• Migration Guide: If necessary, provide a guide or steps for users to migrate their existing code to accommodate these changes.
• API Alignment with Express: Explain how the changes align with the Express API.
• API Longevity: Discuss the steps taken to ensure that the new or updated APIs are consistent and not prone to breaking changes.
• Examples: Provide examples demonstrating the new features or changes in action.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• Enhancement (improvement to existing features and functionality)
• Documentation update (changes to documentation)
• Performance improvement (non-breaking change which improves efficiency)
• Code consistency (non-breaking change which improves code reliability and robustness)

Checklist

Before you submit your pull request, please make sure you meet these requirements:

• Followed the inspiration of the Express.js framework for new functionalities, making them similar in usage.
• [] Conducted a self-review of the code and provided comments for complex or critical parts.
• Updated the documentation in the /docs/ directory for Fiber's documentation.
• Added or updated unit tests to validate the effectiveness of the changes or new features.
• Ensured that new and existing unit tests pass locally with the changes.
• Verified that any new dependencies are essential and have been agreed upon by the maintainers/community.
• Aimed for optimal performance with minimal allocations in the new code.
• Provided benchmarks for the new code to analyze and improve upon.

Commit formatting

Please use emojis in commit messages for an easy way to identify the purpose or intention of a commit. Check out the emoji cheatsheet here: CONTRIBUTING.md

[coderabbitai]

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

The timeout middleware refactoring enforces handler timeouts through concurrent execution with goroutine-based synchronization, panic capture, and context cancellation. The change replaces linear post-execution timeout checks with a select-based control flow that monitors completion, panics, and deadline exceeded conditions, unified through a single error path.

Changes

Cohort / File(s)	Change Summary
Core Timeout Handler Refactoring middleware/timeout/timeout.go	Restructures timeout enforcement from post-execution checks to concurrent execution with goroutine-driven done and panic channels. Introduces safeCall wrapper for panic capture. Integrates context cancellation, custom timeout errors via OnTimeout, and converts panics/deadline-exceeded to unified fiber.ErrRequestTimeout error.
Comprehensive Test Coverage middleware/timeout/timeout_test.go	Adds TestTimeout_Issue_3671 covering multiple timeout scenarios (panic after timeout, blocking handlers, micro/large timeouts, custom OnTimeout behaviors) and TestSafeCall_Panic validating panic-to-timeout error conversion in the safe call wrapper.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Middleware
    participant Handler Goroutine
    participant Done Channel
    participant Panic Channel
    participant Context

    Client->>Middleware: HTTP Request
    Middleware->>Context: Create cancellable context with timeout
    Middleware->>Handler Goroutine: Launch handler in goroutine
    Middleware->>Middleware: Enter select statement
    
    alt Successful Completion
        Handler Goroutine->>Done Channel: Signal completion
        Done Channel->>Middleware: Receive result
        Middleware->>Middleware: Check for custom error
        Middleware->>Client: Return response
    else Timeout/Deadline Exceeded
        Context->>Context: Deadline exceeded
        Context->>Middleware: Context cancellation detected
        Middleware->>Middleware: Invoke OnTimeout callback
        Middleware->>Client: Return fiber.ErrRequestTimeout
    else Panic in Handler
        Handler Goroutine->>Panic Channel: Capture panic
        Panic Channel->>Middleware: Receive panic signal
        Middleware->>Client: Return fiber.ErrRequestTimeout
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Areas requiring extra attention:

• Goroutine synchronization logic in the select statement and channel handling to ensure no race conditions or resource leaks
• Panic capture mechanism in safeCall wrapper and conversion to appropriate timeout error
• Context cancellation propagation and its interaction with deadline-exceeded conditions
• Edge case coverage in tests, particularly the TestTimeout_Issue_3671 scenarios involving concurrent panics and blocking handlers
• Validation that OnTimeout callback is invoked at the correct time and with proper state

Possibly related PRs

• refactor(timeout): unify and enhance timeout middleware #3275: Refactors middleware/timeout/timeout.go to unify timeout handling with runHandler and isCustomError patterns
• 🐛 bug: Fix support for context.Context #3720: Modifies timeout.go to improve context handling (ctx.Context(), SetContext, context.WithTimeout) within the timeout middleware
• 🔥 feat: Add config for Timeout middleware #3604: Updates timeout middleware's error handling and OnTimeout/runHandler invocation logic

Suggested labels

☢️ Bug, v3, codex

Suggested reviewers

• gaby
• sixcolons
• ReneWerner87
• efectn

Poem

🐰 A rabbit's ode to concurrent grace,
Where timeouts now have their rightful place,
Goroutines dance with channels so bright,
Panics are caught—no more endless flight!
Context cancels when time runs thin,
With safeCall guards, the true flow wins! 🎉

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title 'fix: Timeout middleware not enforced' directly relates to the main change—refactoring timeout middleware to properly enforce timeouts—though it uses an emoji and could be more descriptive.
Description check	✅ Passed	Description clearly outlines the refactoring (goroutine, select statement, panic handling) and the issue fixed (#3671), but most checklist items are left unchecked, indicating incomplete documentation, benchmarks, and migration guidance.
Linked Issues check	✅ Passed	The PR addresses issue #3671 requirements: enforces timeouts via goroutine and select, passes cancellable context to handlers, safely propagates panics, and includes comprehensive edge-case tests for these behaviors.
Out of Scope Changes check	✅ Passed	All changes in timeout.go and timeout_test.go are directly scoped to fixing the timeout middleware enforcement and adding required validation tests for issue #3671.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @edvardsanta, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical bug in the Fiber framework's timeout middleware where it failed to properly enforce timeouts, particularly when request handlers blocked indefinitely or panicked after the timeout period. The changes refactor the middleware to execute handlers concurrently, enabling reliable timeout detection and robust panic recovery for both the main handler and custom timeout callbacks. This ensures that the application consistently responds with a Request Timeout status when a handler exceeds its allocated time, significantly improving the middleware's reliability and resilience.

Highlights

• Concurrent Handler Execution: The timeout middleware now executes the wrapped handler in a separate goroutine. This allows the middleware to effectively monitor the handler's execution time independently and enforce timeouts even if the handler blocks indefinitely.
• Improved Timeout Enforcement: The middleware now uses a select statement to wait for one of three events: the handler completing successfully, the handler panicking, or the context timing out. This ensures that timeouts are reliably enforced and appropriate fiber.ErrRequestTimeout responses are returned.
• Enhanced Panic Handling: Robust panic recovery has been implemented for both the main handler and the custom OnTimeout callback. If either panics, the middleware catches the panic and ensures that a fiber.ErrRequestTimeout is returned, preventing application crashes.
• Expanded Test Coverage: Comprehensive new test cases have been added to cover various challenging scenarios, including handlers that block forever, handlers that panic, and situations where the custom OnTimeout callback itself panics.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly refactors the timeout middleware to use a goroutine and a select statement, which properly enforces timeouts. This fixes a fundamental bug in the previous implementation. The new test suite also adds valuable coverage for edge cases. My main feedback is regarding panic handling. The current implementation swallows panics from the handler and returns a timeout error, which can hide critical bugs. I've suggested re-panicking instead to let the framework's standard error handling take over.

[edvardsanta]

Hello, @ReneWerner87, @gaby ,@own2pwn, @sixcolors.

I’m exploring some edge cases around the Timeout middleware and would like your thoughts on expected behavior. Specifically, I’m wondering how Fiber should behave when a panic occurs in the handler. I have written two tests cases:
Handler panics after timeout:

handler: func(_ fiber.Ctx) error {
      time.Sleep(50 * time.Millisecond)
      panic("panic after timeout")
}

Custom OnTimeout handler panics:

handler: func(_ fiber.Ctx) error {
		time.Sleep(50 * time.Millisecond)
		return nil
	},
	config: Config{
		Timeout: 10 * time.Millisecond,
		OnTimeout: func(_ fiber.Ctx) error {
			panic("custom panic on timeout")
		},
},

My questions:

1. In the case of a panic after the timeout has already triggered, should Fiber still return a 408 Request Timeout, or should the panic propagate?

2. For a panic inside a custom OnTimeout handler, do we have an expected status code, or should the panic be allowed to crash the app?

3. Any recommendations on handling these panics safely in production while maintaining the correct timeout semantics?

I’m not sure what the “correct” behavior should be here, so I’d like to align it first before to open the pr

[gaby]

@edvardsanta

1. Return 408
2. Probably 408 too
3. Add tests for them, testify has a way of testing these

[gaby]

@edvardsanta Any updates on this?

[edvardsanta]

@edvardsanta Any updates on this?

I’ll get back to this later today

[Copilot]

Pull Request Overview

This PR fixes the timeout middleware to properly enforce request timeouts in real-time by refactoring the middleware implementation to use goroutines and channels for timeout handling.

Key changes:

• Wraps handler execution in a goroutine with proper panic recovery
• Uses a select statement to handle handler completion, panics, and timeout scenarios
• Ensures timeouts are enforced in real-time rather than only after handler completion

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
middleware/timeout/timeout.go	Refactored timeout enforcement logic using goroutines and channels
middleware/timeout/timeout_test.go	Added comprehensive test cases for edge cases including panics, blocking handlers, and extreme timeout values

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

middleware/timeout/timeout.go (1)

39-50: Panics are being downgraded to ErrRequestTimeout, losing stack traces and misclassifying server bugs

Right now there are two layered mechanisms that turn panics into fiber.ErrRequestTimeout:

• safeCall wraps the whole select and converts any panic in that block (including inside cfg.OnTimeout) to fiber.ErrRequestTimeout.
• In the select, a panic in the handler goroutine is recovered, sent into panicChan, and then treated as a timeout:

case <-panicChan:
    return fiber.ErrRequestTimeout

Consequences:

• A genuine handler bug (panic) is surfaced to the client as a 408 Request Timeout instead of a 500, which is misleading from an HTTP semantics standpoint.
• The original panic and its stack trace never reach Fiber’s usual panic handling path, which makes production debugging significantly harder.
• This also contradicts the stated goal of “panics are safely propagated without losing stack traces”.

A minimal change that restores expected behavior for handler panics while keeping the rest of the logic intact:

@@ func runHandler(c fiber.Ctx, h fiber.Handler, cfg Config) error {
-       case <-panicChan:
-           return fiber.ErrRequestTimeout
+       case p := <-panicChan:
+           // Re-raise the panic so Fiber's global panic handling
+           // can log and classify it as a 500, not a 408 timeout.
+           panic(p)

With this change:

• Handler panics before the timeout will behave like any other Fiber panic (500 + stack).
• In the “panic after timeout” scenario, the timeout will still win the race and return 408, and the later panic will be re‑raised during the handler goroutine, preserving a stack trace rather than being silently swallowed.

Separately, you may want to reconsider whether safeCall should be used around the entire select block at all: right now a panic in cfg.OnTimeout is also mapped to fiber.ErrRequestTimeout, which again hides the root cause. It may be preferable to let OnTimeout panics also propagate (or at least log them explicitly) instead of downgrading them to 408.

Also applies to: 55-88

🧹 Nitpick comments (2)

middleware/timeout/timeout_test.go (2)

215-312: Two table entries reuse the same path, so one scenario isn’t actually exercised

In TestTimeout_Issue_3671, both of these cases use "/panic-ontimeout":

• "Custom OnTimeout handler panics"
• "Custom OnTimeout"

Since you register routes in a loop:

for _, tc := range testCases {
    app.Get(tc.path, New(tc.handler, tc.config))
}

the second registration for "/panic-ontimeout" will shadow the first, and both subtests will hit the last handler only. Because both expect StatusRequestTimeout, this passes but the “Custom OnTimeout handler panics” case isn’t truly covered at the HTTP level.

Suggestion: give each scenario its own unique path (e.g. "/panic-ontimeout" vs "/custom-ontimeout") so both code paths (panic in OnTimeout vs normal OnTimeout) are actually exercised.

---

314-321: TestSafeCall_Panic couples tests to the current “panic == timeout” behavior

This test asserts that any panic wrapped by safeCall becomes fiber.ErrRequestTimeout:

err := safeCall(func() error { panic("test panic") })
require.Equal(t, fiber.ErrRequestTimeout, err)

If you adopt a model where handler panics (or OnTimeout panics) are re‑raised to go through Fiber’s global panic handling (to preserve stack traces and yield 500s), this test will need to be updated accordingly—either to:

• expect a re‑panic, or
• restrict safeCall’s use to only those places where you truly want to convert a panic into a timeout-like error.

As it stands, the test locks in the “panic becomes timeout” behavior, so any change in the runtime panic semantics should be reflected here.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5caa478 and 073ed97.

📒 Files selected for processing (2)

• middleware/timeout/timeout.go (1 hunks)
• middleware/timeout/timeout_test.go (1 hunks)

🧰 Additional context used

🧠 Learnings (12)

📓 Common learnings

Learnt from: efectn
Repo: gofiber/fiber PR: 3162
File: app_test.go:893-895
Timestamp: 2024-11-29T12:37:27.581Z
Learning: In the `Test_App_ShutdownWithContext` function in `app_test.go`, the `clientDone` channel is used to synchronize the client's request completion before proceeding, eliminating the need for additional `time.Sleep` calls.

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3016
File: middleware/session/middleware_test.go:190-191
Timestamp: 2024-09-25T17:05:06.991Z
Learning: When testing session `IdleTimeout` expiration, it's acceptable to use `time.Sleep` to simulate the passage of time in tests.

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3016
File: middleware/session/middleware_test.go:190-191
Timestamp: 2024-10-12T10:01:44.206Z
Learning: When testing session `IdleTimeout` expiration, it's acceptable to use `time.Sleep` to simulate the passage of time in tests.

📚 Learning: 2025-05-08T08:14:37.302Z

Learnt from: mdelapenya
Repo: gofiber/fiber PR: 3434
File: app.go:623-636
Timestamp: 2025-05-08T08:14:37.302Z
Learning: In the gofiber/fiber framework, service startup failures should panic rather than allowing the application to continue running with degraded functionality, as this is the agreed-upon design decision.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2025-10-16T07:19:52.418Z

Learnt from: grivera64
Repo: gofiber/fiber PR: 3807
File: adapter_test.go:118-144
Timestamp: 2025-10-16T07:19:52.418Z
Learning: In the Fiber codebase, the linter does not allow `require` assertions from within HTTP handlers (including net/http-style handlers). Use `t.Fatalf`, `t.Errorf`, or similar `testing.T` methods for error handling inside handler functions instead.

Applied to files:

• middleware/timeout/timeout.go
• middleware/timeout/timeout_test.go

📚 Learning: 2024-10-08T19:06:06.583Z

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3016
File: middleware/session/config.go:122-122
Timestamp: 2024-10-08T19:06:06.583Z
Learning: In `DefaultErrorHandler(c *fiber.Ctx, err error)`, since `c` is a pointer to an interface, we need to dereference `*c` when calling interface methods like `SendStatus`.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2024-09-25T17:05:06.991Z

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3016
File: middleware/session/middleware_test.go:190-191
Timestamp: 2024-09-25T17:05:06.991Z
Learning: When testing session `IdleTimeout` expiration, it's acceptable to use `time.Sleep` to simulate the passage of time in tests.

Applied to files:

• middleware/timeout/timeout.go
• middleware/timeout/timeout_test.go

📚 Learning: 2024-12-01T10:28:36.011Z

Learnt from: ReneWerner87
Repo: gofiber/fiber PR: 0
File: :0-0
Timestamp: 2024-12-01T10:28:36.011Z
Learning: Feature request #3224 has been created to add support for square bracket notation and comma-separated values in multipart form data in Fiber, while maintaining binary data transfer capabilities. This would bring parity with the existing form-urlencoded functionality.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2024-11-15T07:56:21.623Z

Learnt from: ReneWerner87
Repo: gofiber/fiber PR: 3161
File: app.go:923-932
Timestamp: 2024-11-15T07:56:21.623Z
Learning: In the Fiber framework, breaking changes are acceptable when moving from version 2 to version 3, including modifications to method signatures such as in the `Test` method in `app.go`.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2025-05-13T00:19:16.407Z

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3446
File: docs/middleware/logger.md:44-44
Timestamp: 2025-05-13T00:19:16.407Z
Learning: In documentation files for the Fiber framework, code examples are often partial and don't repeat import statements that were shown in earlier examples, focusing instead on demonstrating specific usage patterns.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2024-07-15T19:53:36.605Z

Learnt from: luk3skyw4lker
Repo: gofiber/fiber PR: 3074
File: router_test.go:372-397
Timestamp: 2024-07-15T19:53:36.605Z
Learning: There's no short-term plan to support concurrency on the `RebuildTree` method in the Fiber framework as per luk3skyw4lker.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2025-11-13T11:34:38.503Z

Learnt from: efectn
Repo: gofiber/fiber PR: 3824
File: listen_test.go:560-564
Timestamp: 2025-11-13T11:34:38.503Z
Learning: The gofiber/fiber project only supports the latest Go versions, so Go 1.22+ syntax features (such as `for range N` integer range loops) are acceptable and preferred.

Applied to files:

• middleware/timeout/timeout.go

📚 Learning: 2024-06-30T00:38:06.580Z

Learnt from: sixcolors
Repo: gofiber/fiber PR: 3051
File: middleware/session/session.go:215-216
Timestamp: 2024-06-30T00:38:06.580Z
Learning: Parallel tests for `Session.Save` already exist in the `middleware/session/session_test.go` file, specifically in the `Test_Session_Save` and `Test_Session_Save_Expiration` functions.

Applied to files:

• middleware/timeout/timeout_test.go

📚 Learning: 2024-11-29T12:37:27.581Z

Learnt from: efectn
Repo: gofiber/fiber PR: 3162
File: app_test.go:893-895
Timestamp: 2024-11-29T12:37:27.581Z
Learning: In the `Test_App_ShutdownWithContext` function in `app_test.go`, the `clientDone` channel is used to synchronize the client's request completion before proceeding, eliminating the need for additional `time.Sleep` calls.

Applied to files:

• middleware/timeout/timeout_test.go

🧬 Code graph analysis (2)

middleware/timeout/timeout.go (3)

constants.go (1)

• ErrRequestTimeout (126-126)

ctx_interface_gen.go (1)

• Ctx (18-432)

middleware/timeout/config.go (1)

• Config (10-26)

middleware/timeout/timeout_test.go (4)

middleware/timeout/timeout.go (1)

• New (14-37)

middleware/timeout/config.go (1)

• Config (10-26)

ctx_interface_gen.go (1)

• Ctx (18-432)

constants.go (4)

• StatusRequestTimeout (81-81)
• StatusOK (52-52)
• MethodGet (5-5)
• ErrRequestTimeout (126-126)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: repeated
• GitHub Check: Compare
• GitHub Check: lint

🔇 Additional comments (1)

middleware/timeout/timeout.go (1)

17-37: New middleware wiring and context restoration look sound

The wrapper correctly:

• skips on cfg.Next,
• sets up a per-request timeout context when Timeout > 0,
• restores the original context and calls cancel() via defer even when the handler returns an error or panics (assuming we re‑panic from inside runHandler).

Calling runHandler in both the timeout and non-timeout branches keeps the behavior centralized and consistent.