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.

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 or fill out our survey to provide feedback.

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.

docs/middleware/timeout.md (1)

129-141: Improve DB example: error handling and transaction rollback

• Check and handle errors from gorm.Open/Begin.
• Roll back on any failure to avoid leaving open transactions.
• Keep the context usage as-is.

-    handler := func(ctx fiber.Ctx) error {
-        tran := db.WithContext(ctx.Context()).Begin()
-        
-        if tran = tran.Exec("SELECT pg_sleep(50)"); tran.Error != nil {
-            return tran.Error
-        }
-        
-        if tran = tran.Commit(); tran.Error != nil {
-            return tran.Error
-        }
-
-        return nil
-    }
+    handler := func(ctx fiber.Ctx) error {
+        tx := db.WithContext(ctx.Context()).Begin()
+        if tx.Error != nil {
+            return tx.Error
+        }
+        if err := tx.Exec("SELECT pg_sleep(50)").Error; err != nil {
+            _ = tx.Rollback().Error
+            return err
+        }
+        if err := tx.Commit().Error; err != nil {
+            _ = tx.Rollback().Error
+            return err
+        }
+        return nil
+    }

docs/middleware/timeout.md (2)

97-101: Handle parse errors consistently

Mirror the basic example: validate sleepTime and return 400 on bad input.

-        sleepTime, _ := time.ParseDuration(c.Params("sleepTime") + "ms")
+        sleepStr := c.Params("sleepTime")
+        sleepTime, err := time.ParseDuration(sleepStr + "ms")
+        if err != nil {
+            return fiber.NewError(fiber.StatusBadRequest, "invalid sleepTime")
+        }

---

57-63: Handle parse errors and flip error-wrapping order

• Return 400 on invalid delay instead of ignoring the error.
• Prefer “context: %w” ordering for error wrapping.

-    handler := func(c fiber.Ctx) error {
-        delay, _ := time.ParseDuration(c.Params("delay") + "ms")
-        if err := sleepWithContext(c.Context(), delay); err != nil {
-            return fmt.Errorf("%w: execution error", err)
-        }
-        return c.SendString("finished")
-    }
+    handler := func(c fiber.Ctx) error {
+        delayStr := c.Params("delay")
+        delay, err := time.ParseDuration(delayStr + "ms")
+        if err != nil {
+            return fiber.NewError(fiber.StatusBadRequest, "invalid delay")
+        }
+        if err := sleepWithContext(c.Context(), delay); err != nil {
+            return fmt.Errorf("execution error: %w", err)
+        }
+        return c.SendString("finished")
+    }

docs/middleware/timeout.md (5)

7-10: Clarify cancellation requirement for handlers

Add an explicit note that handlers must actively observe c.Context().Done() and stop work, otherwise the goroutine may continue running even after the 408 is sent.

---

12-16: Strengthen “Do/Don’t” with explicit examples

Consider adding a small “Do vs Don’t” snippet to make misuse obvious.

// Don't: global use (will panic)
app.Use(timeout.New(h))

// Do: wrap the final handler per route
app.Get("/foo", timeout.New(h, timeout.Config{Timeout: 2 * time.Second}))

---

33-52: Avoid potential timer leak; prefer time.NewTimer with stop/drain

Using time.After prevents canceling the timer if the context fires first. Suggest using time.NewTimer and stopping/draining it on cancellation.

-func sleepWithContext(ctx context.Context, d time.Duration) error {
-    select {
-    case <-time.After(d):
-        return nil
-    case <-ctx.Done():
-        return ctx.Err()
-    }
-}
+func sleepWithContext(ctx context.Context, d time.Duration) error {
+    timer := time.NewTimer(d)
+    defer func() {
+        if !timer.Stop() {
+            <-timer.C
+        }
+    }()
+    select {
+    case <-timer.C:
+        return nil
+    case <-ctx.Done():
+        return ctx.Err()
+    }
+}

---

73-78: Optional: show explicit timeout behavior in curl

Consider adding examples with timing to make the difference visible:

time curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000/sleep/1000
time curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000/sleep/3000

---

125-128: Optional: acknowledge omitted imports for partial snippet

Consider a brief note that imports/DSN handling are omitted for brevity, consistent with other Fiber docs.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Learnt from: sixcolors
PR: gofiber/fiber#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.

Learnt from: gaby
PR: gofiber/fiber#3193
File: middleware/adaptor/adaptor.go:111-111
Timestamp: 2024-11-10T23:44:13.704Z
Learning: In the `middleware/adaptor/adaptor.go` file of the Fiber framework, when updating context handling, replacing `c.Context()` with `c.RequestCtx()` is appropriate to access the `fasthttp.RequestCtx`.