🔥 Feature: Add Req and Res API #2894

nickajacks1 · 2024-03-03T23:21:35Z

CURRENT STATUS

Description

Split the existing Ctx API into two separate APIs for Requests and Responses. Having distinct APIs for Request and Response types will allow developers to more easily write self-documenting code by avoiding ambiguous methods such as Ctx.Cookie and Ctx.Cookies. Much of the existing Ctx API simply calls the corresponding Req or Res API. For example, Ctx.Get calls Request.Get and Ctx.Set calls Response.Set.

Because Express defines only res and req APIs with no context API, this change will make it easier to manage Fiber's adherence to Express's APIs. In addition, it will allow us to avoid needing to create certain one-off methods. For example, Ctx.GetRespHeader can now become Ctx.Res().Get

Although the majority of the Ctx API is unchanged, Ctx.Request and Ctx.Response have been removed in favor of Ctx.Req and Ctx.Res. Now, instead of a raw fasthttp.Request or fasthttp.Response, we return fiber.Request and fiber.Response objects, which implement their respective APIs. As such, this is a breaking change for users who access Ctx.Request and Ctx.Response direct.

Inspired by Koa and fasthttp, both of which have individual request/response objects and a single context object whose methods are simply aliases for corresponding methods on the req/res APIs.

Deprecation:

Ctx.GetRespHeader is replaced by Ctx.Res().Get

Related to #2854

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.

coderabbitai · 2024-03-03T23:21:41Z

Walkthrough

The updates introduce modifications to the DefaultCtx struct within the fiber package, adding new fields for request and response handling. New methods Req() and Res() facilitate access to these fields. Additionally, the NewDefaultCtx function is updated to initialize these fields. New structs DefaultReq and DefaultRes are introduced, each containing multiple methods that delegate functionality to the underlying context. Corresponding interfaces Req and Res are also defined, encapsulating request and response functionalities.

Changes

Files	Summary of Changes
`ctx.go`, `ctx_interface.go`, `ctx_interface_gen.go`	Added fields `req` and `res` to `DefaultCtx`, implemented methods `Req()` and `Res()`, and updated `NewDefaultCtx`.
`req.go`, `req_interface_gen.go`	Introduced `DefaultReq` struct with multiple methods for handling HTTP request data and defined a corresponding `Req` interface.
`res.go`, `res_interface_gen.go`	Introduced `DefaultRes` struct with various response handling methods and defined a corresponding `Res` interface.
`ctx_test.go`	Updated test methods to replace direct context calls with calls to `Req()` and `Res()` methods for improved clarity.
`docs/api/ctx.md`	Restructured and renamed several context methods, removing outdated methods and introducing new ones for better functionality.

Possibly related PRs

🔥 Feature (v3): Add buffered streaming support #3131: The changes in the main PR, which involve adding new fields and methods to the DefaultCtx struct, are related to the modifications in the retrieved PR that also adds a new method to the same DefaultCtx struct, indicating a direct connection at the code level.
🔥 feat: Add Context Support to RequestID Middleware #3200: The changes in the main PR, which involve adding fields and methods to the DefaultCtx struct for request and response handling, are related to the retrieved PR that modifies the requestid middleware to enhance context management by integrating the request ID into the fiber.Ctx object, as both involve modifications to the context structure and its methods.
📚 Doc: Updates to Context documentation #3206: The changes in the main PR, which involve adding fields and methods to the DefaultCtx struct, are related to the modifications in the retrieved PR that update the documentation for the Ctx interface, as both pertain to the context handling in the fiber package.

Suggested reviewers

sixcolors
ReneWerner87
efectn

🐰✨
In the land of code where the bits align,
A rabbit hopped through, refactoring fine.
From request to response, through headers it weaved,
A tapestry of changes, expertly conceived.
Celebrate the craft, for improvements shine bright,
In the glow of the code, under the moonlight. 🌙
🌟🐇

✨ Finishing Touches

📝 Generate Docstrings

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Generate unit testing code for this file.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai generate unit testing code for this file.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and generate unit testing code.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

client.go

codecov · 2024-03-05T03:37:13Z

Codecov Report

Attention: Patch coverage is 29.92701% with 96 lines in your changes missing coverage. Please review.

Project coverage is 83.66%. Comparing base (6afba95) to head (64dd9bb).

Files with missing lines	Patch %	Lines
req.go	16.21%	62 Missing ⚠️
res.go	37.03%	34 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2894      +/-   ##
==========================================
- Coverage   84.29%   83.66%   -0.64%     
==========================================
  Files         116      118       +2     
  Lines       11572    11708     +136     
==========================================
+ Hits         9755     9795      +40     
- Misses       1389     1485      +96     
  Partials      428      428

Flag	Coverage Δ
unittests	`83.66% <29.92%> (-0.64%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

gaby · 2024-03-05T03:46:30Z

@nickajacks1 Just so you are aware, the tests are very unstable/flaky right now in main. This is because we no longer retry failed tests multiple times on the CI. This is being fixing in #2892

nickajacks1 · 2024-03-10T00:04:56Z

3/9: Moved some more methods from Ctx to Request. Rebased.

nickajacks1 · 2024-03-18T01:15:30Z

3/17: Rebase. Moved more trivial methods to Request.

nickajacks1 · 2024-04-15T00:23:53Z

Hi @gofiber/maintainers

Sorry this is taking so long.
I've reached the first major milestone - the Request API is fully moved over to the Request type.
I'd like to get a health check - does the overall direction still seem OK? If so, I suspect that moving the Response API over will be comparatively quick.
None of the unit tests have been moved over. IMO that's quite a bit of work and shouldn't hold up v3 since it's not public facing and can be done at any time.

nickajacks1 · 2024-04-21T17:23:38Z

Even though Express has Locals as part of the res API, I feel like it makes more sense to keep it as part of Ctx since it doesn't inherently have anything to do with the response (or request for that matter). I'm going to leave in Ctx for now.

ReneWerner87 · 2024-04-21T19:36:00Z

ok, sounds reasonable we can always adapt it later

nickajacks1 · 2024-04-21T21:39:56Z

Ok, the Response API is fully moved over.

Some remaining work:
I didn't move Redirect to the Response API yet. The Redirect API has some dependencies on DefaultCtx that requires more thought. Moving Redirect to Res won't break the API in any way, so we can take our time thinking about this.

Next week I'll start on either the docs or the interface part.

nickajacks1 · 2024-05-12T17:13:02Z

I was thinking, is it actually that useful to make Request and Response interfaces if Ctx is already an interface and can thus be expanded instead of Request/Response? If we say that custom extensions should just go through Ctx, that might simplify both the API and implementation a bit.
Thoughts @gofiber/maintainers ?

sixcolors · 2024-05-13T00:20:05Z

I was thinking, is it actually that useful to make Request and Response interfaces if Ctx is already an interface and can thus be expanded instead of Request/Response? If we say that custom extensions should just go through Ctx, that might simplify both the API and implementation a bit. Thoughts @gofiber/maintainers ?

I am interested in learning more about the approach of expanding the Ctx interface for custom extensions, instead of introducing separate Request and Response interfaces. Could you please explain how this approach works and how it simplifies the API for developers?

In addition, can you help us by merging the changes added to the main branch, and updating your PR to use the new Bind() interface?

Thank you, great work so far, and I look forward to your reply!

nickajacks1 · 2024-05-13T01:06:16Z

I am interested in learning more about the approach of expanding the Ctx interface for custom extensions, instead of introducing separate Request and Response interfaces. Could you please explain how this approach works and how it simplifies the API for developers?

The two primary points I have in mind are:

Any extension of behavior can already be handled by using a custom Ctx since the split implementation is at its core a kind of syntactic sugar. I have not been able to think of a use case for Req/Res interfaces that can't be handled with the Ctx interface.
Since the Ctx and Request+Response APIs have overlap, it may be less clear to developers which they should implement. If they want to update SendString to tee out some logs, should they do it by making a custom Ctx or a custom Respose? I feel like having either Ctx or Request+Response be interfaces may be more straightforward (and I lean toward Ctx). This is more what I meant when I implied that having all three of Ctx, Request, and Response be interfaces could make the API more complex.

In addition, can you help us by merging the changes added to the main branch, and updating your PR to use the new Bind() interface?

ye. will also probably be able to mark the PR ready for review soon.

nickajacks1 · 2024-05-13T01:36:43Z

Marking as ready for review. If it is decided to make Request and Response interfaces, I will update the PR.
Regarding the docs, I think it might be better to get this in first and then write up the docs.

* Sprinkle in calls to Req() and Res() to a few unit tests * Fix improper initialization caught by ^ * Add a few missing methods

nickajacks1 · 2025-02-17T01:50:10Z

@ReneWerner87 this could probably be merged whenever

ReneWerner87 · 2025-02-17T07:02:01Z

Ok i will check it today, sorry lost focus last time

ReneWerner87 · 2025-02-17T11:08:02Z

@sixcolors @gaby @efectn let's recheck it so we can merge this big adjustment

ReneWerner87 · 2025-02-17T12:34:32Z

@nickajacks1 looks good to me, but can you please provide some more tests for the use of req/resp

ReneWerner87 · 2025-02-17T12:37:46Z

I had seen that you had customized the current ones, but I would find it better if you added additional ones
so that the use with the direct use of req/res is tested and if you use it directly from the context object
performance technically, do we still need to create pools for the objects ? to minimize the allocations in the process and then reset them when clearing the context ?

grivera64 · 2025-02-18T01:06:24Z

Thanks for working on this PR! It will be quite useful for distinguishing between Request and Response-based methods in Ctx.

I have an idea that could help with this bulletpoint from above:

performance technically, do we still need to create pools for the objects ? to minimize the allocations in the process and then reset them when clearing the context ?

From reviewing the PR, could we theoretically use an interface for Req and Res instead of a dedicated struct to avoid allocations/clearing altogether (aside from the already done allocation/clearing for the DefaultCtx struct) for performance?

I'm not entirely sure if it’s idiomatic to do this in Go, but we could set up Ctx, Req, and Res like in the following example:

// All Req and Res-based methods
type Ctx interface {
  Queries() map[string]string
  SendString(body string) error
  // …
}

// Req - Request-based Ctx methods
type Req interface {
  Queries() map[string]string
  // …
}

// Res - Response-based Ctx methods
type Res interface {
  SendString(body string) error
  // …
}

We would need to look more into it, but this could potentially be autogenerated in the same way that Ctx is currently generated by ifacemaker. Then, all we would need is to rewrite (*DefaultCtx).Req() and (*DefaultCtx).Res() as:

func (c *DefaultCtx) Req() Req {
  return c
}

func (c *DefaultCtx) Res() Res {
  return c
}

If we do this, it should not allocate any new memory but rather cast the Ctx interface to a sub-interface for Req or Res. This would also eliminate the need to create any new methods for Req and Res directly when a new feature is added to Ctx.

If this idea wouldn't work well with this PR, I agree that we could also just add a pool for low memory footprint. I believe that and adding tests for the old and new v3 Ctx methods (e.g. c.SendStreamWriter()) would be all that is left before this is ready to merge.

Thanks again for the PR!

ReneWerner87 · 2025-02-20T08:00:54Z

@grivera64 in the first iteration i would like to go with this concept and after that you can show the new concept via pr or issue report
in the end, nothing should change in the usage, so that there is no breaking change, even if we do it in two steps

ReneWerner87 · 2025-02-20T11:28:01Z

@nickajacks1 are you working on the last comments ?

nickajacks1 · 2025-02-20T13:14:45Z

@ReneWerner87 Yes, I will work on this on Friday. Can you give a brief example of what kind of tests you would like to see

ReneWerner87 · 2025-02-20T14:28:42Z

the previous tests you changed in ctx should be reset and you should create test files for the req and resp struct that test the existing functions
similar to what happens in ctx

theoretically, the function used in the req or resp object could also contain additional code or a new method could exist
of course it is currently only forwarded, but we don't know what we plan to do with it in the future
every test should therefore test the function of the underlying method

it may also be that it is too much of a good thing, because we currently know that we are only forwarding, but theoretically you could also adjust the parameters and return in the respective wrapper methods so that it can be used better

grivera64 · 2025-02-20T22:56:58Z

@grivera64 in the first iteration i would like to go with this concept and after that you can show the new concept via pr or issue report in the end, nothing should change in the usage, so that there is no breaking change, even if we do it in two steps

For sure, sounds good to me! After this is merged, I can create an issue/PR with the new concept so we can discuss more about it.

nickajacks1 · 2025-02-21T23:49:55Z

I just realized how many tests there are 😁
I thought of some ways to do this

Duplicate all tests for Req and Res
Create smaller smoke tests for Req and Res that are more compact/not as thorough
Somehow templatize the tests so that they end up in a format like

func testAccepts(t *testing.T, r Req) {}
func TestAccepts(t *testing.T) {
    app := New()
    c := app.AcquireCtx(&fasthttp.RequestCtx{})
    t.Run("ctx", func(t *testing.T) { testAccepts(t, c) })
    t.Run("req", func(t *testing.T) { testAccepts(t, c.Req()) })
}

what do folks think? 3 sounds potentially nice but would have a huge impact to the tests and be a lot of work and potentially increased cognitive overhead. 1 seems overkill and prone to subtle drift unless the duplicated tests were generated somehow. 2 seems reasonable to me.

By the way, even with these changes, there are no additional allocations (I checked Benchmark_Ctx_AcquireReleaseFlow). That said, I kind of like @grivera64 's idea of simply having req and res be views onto the Ctx interface rather than bespoke objects.

ReneWerner87 · 2025-02-22T07:00:04Z

I like idea 2 and 3

Btw we also need to somehow duplicate the docs

Updated the documentation in the /docs/ directory for Fiber's documentation.

nickajacks1 · 2025-02-24T01:02:20Z

Update: rearranged docs. Added some methods I missed. Have not added tests yet.

coderabbitai

Actionable comments posted: 1

♻️ Duplicate comments (1)

req.go (1)
9-11: 🛠️ Refactor suggestion

Validate ctx to avoid nil pointer dereferences.

Consider adding a constructor or an internal check to ensure ctx is not nil. Without this safeguard, dereferencing a nil ctx would lead to a runtime panic.
+// NewDefaultReq creates a new DefaultReq and validates the ctx parameter.
+func NewDefaultReq(ctx *DefaultCtx) *DefaultReq {
+    if ctx == nil {
+        panic("DefaultCtx cannot be nil")
+    }
+    return &DefaultReq{ctx: ctx}
+}

🧹 Nitpick comments (3)

res.go (1)
1-4: Group imports for better organization.

The imports should be grouped using parentheses for consistency.
-import "bufio"
+import (
+  "bufio"
+)
🧰 Tools

🪛 GitHub Check: lint

[failure] 3-3:
should only use grouped 'import' declarations (grouper)
docs/api/ctx.md (2)

288-288: Improve documentation readability and clarity.

Several minor improvements can enhance the documentation:

Add missing commas in appropriate places:

After "Please read" in the Fasthttp Documentation section

After "Please use" in the TrustProxy section

Remove redundant phrases:

Replace "outside of" with "outside"

Replace "in order to" with "to"

Replace "take a look at" with "see" or "refer to"

Add missing articles:

Add "The" before "Method is used to save"

Add "The" before "Method is used to save" in SaveFileToStorage section

Fix compound sentences:

Add a comma before "and" in compound sentences where appropriate

Also applies to: 316-316, 590-590, 672-672, 1237-1237, 1270-1270, 1308-1308, 1883-1883

🧰 Tools

🪛 LanguageTool

[typographical] ~288-~288: Consider adding a comma here.
Context: ...tCtx() *fasthttp.RequestCtx ``` :::info Please read the [Fasthttp Documentation](https...

(PLEASE_COMMA)

1394-1584: Update cookie documentation to include security best practices.

The cookie documentation should include security best practices and recommendations for:

Setting secure flags

Using SameSite attribute

Handling HttpOnly cookies

Cookie expiration best practices

📜 Review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between 2b891e8 and 0598cb0.

📒 Files selected for processing (5)

docs/api/ctx.md (30 hunks)
req.go (1 hunks)
req_interface_gen.go (1 hunks)
res.go (1 hunks)
res_interface_gen.go (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

docs/api/ctx.md (1)

Learnt from: gaby
PR: gofiber/fiber#3170
File: ctx.go:1825-1826
Timestamp: 2024-11-12T14:10:51.810Z
Learning: In the Fiber framework, the `IsProxyTrusted()` function returns `true` when `TrustProxy` is `false`, maintaining compatibility with version 2 behavior.

🪛 GitHub Check: codecov/patch

req.go

[warning] 17-18: req.go#L17-L18
Added lines #L17 - L18 were not covered by tests

[warning] 21-22: req.go#L21-L22
Added lines #L21 - L22 were not covered by tests

[warning] 25-26: req.go#L25-L26
Added lines #L25 - L26 were not covered by tests

[warning] 29-30: req.go#L29-L30
Added lines #L29 - L30 were not covered by tests

[warning] 33-34: req.go#L33-L34
Added lines #L33 - L34 were not covered by tests

[warning] 37-38: req.go#L37-L38
Added lines #L37 - L38 were not covered by tests

[warning] 41-42: req.go#L41-L42
Added lines #L41 - L42 were not covered by tests

[warning] 53-54: req.go#L53-L54
Added lines #L53 - L54 were not covered by tests

[warning] 57-58: req.go#L57-L58
Added lines #L57 - L58 were not covered by tests

[warning] 61-62: req.go#L61-L62
Added lines #L61 - L62 were not covered by tests

[warning] 65-66: req.go#L65-L66
Added lines #L65 - L66 were not covered by tests

[warning] 69-70: req.go#L69-L70
Added lines #L69 - L70 were not covered by tests

[warning] 77-78: req.go#L77-L78
Added lines #L77 - L78 were not covered by tests

[warning] 81-82: req.go#L81-L82
Added lines #L81 - L82 were not covered by tests

[warning] 89-90: req.go#L89-L90
Added lines #L89 - L90 were not covered by tests

[warning] 93-94: req.go#L93-L94
Added lines #L93 - L94 were not covered by tests

[warning] 97-98: req.go#L97-L98
Added lines #L97 - L98 were not covered by tests

[warning] 101-102: req.go#L101-L102
Added lines #L101 - L102 were not covered by tests

[warning] 105-106: req.go#L105-L106
Added lines #L105 - L106 were not covered by tests

[warning] 109-110: req.go#L109-L110
Added lines #L109 - L110 were not covered by tests

[warning] 113-114: req.go#L113-L114
Added lines #L113 - L114 were not covered by tests

[warning] 117-118: req.go#L117-L118
Added lines #L117 - L118 were not covered by tests

[warning] 125-126: req.go#L125-L126
Added lines #L125 - L126 were not covered by tests

[warning] 129-130: req.go#L129-L130
Added lines #L129 - L130 were not covered by tests

[warning] 133-134: req.go#L133-L134
Added lines #L133 - L134 were not covered by tests

[warning] 137-138: req.go#L137-L138
Added lines #L137 - L138 were not covered by tests

[warning] 141-142: req.go#L141-L142
Added lines #L141 - L142 were not covered by tests

[warning] 145-146: req.go#L145-L146
Added lines #L145 - L146 were not covered by tests

[warning] 149-150: req.go#L149-L150
Added lines #L149 - L150 were not covered by tests

[warning] 153-154: req.go#L153-L154
Added lines #L153 - L154 were not covered by tests

🪛 GitHub Check: lint

req.go

[failure] 109-109:
unused-parameter: parameter 'override' seems to be unused, consider removing or renaming it as _ (revive)

res.go

[failure] 3-3:
should only use grouped 'import' declarations (grouper)

🪛 GitHub Actions: golangci-lint

req.go

[warning] 109-109: unused-parameter: parameter 'override' seems to be unused, consider removing or renaming it as _ (revive)

🪛 LanguageTool

docs/api/ctx.md

[typographical] ~288-~288: Consider adding a comma here.
Context: ...tCtx() *fasthttp.RequestCtx ``` :::info Please read the [Fasthttp Documentation](https...

(PLEASE_COMMA)

[style] ~316-~316: This phrase is redundant. Consider using “outside”.
Context: ...x *fasthttp.RequestCtx) ``` It is used outside of the Fiber Handlers to reset the context...

(OUTSIDE_OF)

[style] ~590-~590: Consider a shorter alternative to avoid wordiness.
Context: ... information from a ClientHello message in order to guide application logic in the `GetCert...

(IN_ORDER_TO_PREMIUM)

[uncategorized] ~672-~672: Use a comma before “and” if it connects two independent clauses (unless they are closely connected and short).
Context: ...icate that the client cache is now stale and the full response should be sent. When...

(COMMA_COMPOUND_SENTENCE_2)

[uncategorized] ~1237-~1237: Possible missing article found.
Context: ...0, 700] } } }) ``` ### SaveFile Method is used to save any multipart file ...

(AI_HYDRA_LEO_MISSING_THE)

[uncategorized] ~1270-~1270: Possible missing article found.
Context: ... err } }) ``` ### SaveFileToStorage Method is used to save any multipart file ...

(AI_HYDRA_LEO_MISSING_THE)

[typographical] ~1308-~1308: Consider adding a comma here.
Context: ...porhttps for TLS requests. :::info Please use [Config.TrustProxy`](fiber.md#trus...

(PLEASE_COMMA)

[style] ~1883-~1883: To make your writing clearer, consider a more direct alternative.
Context: ...want to use another view engine, please take a look at our [Template middleware](h...

(TAKE_A_LOOK)

⏰ Context from checks skipped due to timeout of 90000ms (3)

GitHub Check: unit (1.23.x, windows-latest)
GitHub Check: repeated
GitHub Check: Compare

🔇 Additional comments (5)

req_interface_gen.go (1)

1-49: Interface definition looks good.

This auto-generated interface file strictly declares method signatures without any implementation details. It appears consistent with the existing naming conventions in the fiber package. No immediate changes are required here, but consider ensuring corresponding doc comments are placed in upstream definitions if needed.

req.go (1)

13-159: Add unit tests to improve coverage.

Most of these delegating methods are not tested, as indicated by static analysis. While they simply wrap r.ctx calls, unit tests can confirm that each method delegates correctly, helping maintain stable and predictable behavior.

🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 17-18: req.go#L17-L18
Added lines #L17 - L18 were not covered by tests

[warning] 21-22: req.go#L21-L22
Added lines #L21 - L22 were not covered by tests

[warning] 25-26: req.go#L25-L26
Added lines #L25 - L26 were not covered by tests

[warning] 29-30: req.go#L29-L30
Added lines #L29 - L30 were not covered by tests

[warning] 33-34: req.go#L33-L34
Added lines #L33 - L34 were not covered by tests

[warning] 37-38: req.go#L37-L38
Added lines #L37 - L38 were not covered by tests

[warning] 41-42: req.go#L41-L42
Added lines #L41 - L42 were not covered by tests

[warning] 53-54: req.go#L53-L54
Added lines #L53 - L54 were not covered by tests

[warning] 57-58: req.go#L57-L58
Added lines #L57 - L58 were not covered by tests

[warning] 61-62: req.go#L61-L62
Added lines #L61 - L62 were not covered by tests

[warning] 65-66: req.go#L65-L66
Added lines #L65 - L66 were not covered by tests

[warning] 69-70: req.go#L69-L70
Added lines #L69 - L70 were not covered by tests

[warning] 77-78: req.go#L77-L78
Added lines #L77 - L78 were not covered by tests

[warning] 81-82: req.go#L81-L82
Added lines #L81 - L82 were not covered by tests

[warning] 89-90: req.go#L89-L90
Added lines #L89 - L90 were not covered by tests

[warning] 93-94: req.go#L93-L94
Added lines #L93 - L94 were not covered by tests

[warning] 97-98: req.go#L97-L98
Added lines #L97 - L98 were not covered by tests

[warning] 101-102: req.go#L101-L102
Added lines #L101 - L102 were not covered by tests

[warning] 105-106: req.go#L105-L106
Added lines #L105 - L106 were not covered by tests

[warning] 109-110: req.go#L109-L110
Added lines #L109 - L110 were not covered by tests

[warning] 113-114: req.go#L113-L114
Added lines #L113 - L114 were not covered by tests

[warning] 117-118: req.go#L117-L118
Added lines #L117 - L118 were not covered by tests

[warning] 125-126: req.go#L125-L126
Added lines #L125 - L126 were not covered by tests

[warning] 129-130: req.go#L129-L130
Added lines #L129 - L130 were not covered by tests

[warning] 133-134: req.go#L133-L134
Added lines #L133 - L134 were not covered by tests

[warning] 137-138: req.go#L137-L138
Added lines #L137 - L138 were not covered by tests

[warning] 141-142: req.go#L141-L142
Added lines #L141 - L142 were not covered by tests

[warning] 145-146: req.go#L145-L146
Added lines #L145 - L146 were not covered by tests

[warning] 149-150: req.go#L149-L150
Added lines #L149 - L150 were not covered by tests

[warning] 153-154: req.go#L153-L154
Added lines #L153 - L154 were not covered by tests

🪛 GitHub Check: lint

[failure] 109-109:
unused-parameter: parameter 'override' seems to be unused, consider removing or renaming it as _ (revive)

🪛 GitHub Actions: golangci-lint

[warning] 109-109: unused-parameter: parameter 'override' seems to be unused, consider removing or renaming it as _ (revive)

res_interface_gen.go (1)

1-39: Interface definition looks consistent.

This auto-generated interface file cleanly outlines the response API. Ensure updates to the underlying implementation in DefaultRes remain in sync, and verify that doc comments for these methods exist in upstream definitions if needed.
res.go (2)

5-8: LGTM! Well-structured struct definition.

The DefaultRes struct follows good design practices with proper encapsulation and clear naming. The go:generate directive ensures proper interface generation.

10-117: Add unit tests for response API methods.

The response API methods lack test coverage. This is critical for ensuring the delegation pattern works correctly and maintaining reliability during future changes.

Would you like me to help generate comprehensive unit tests for these methods?

Consider standardizing return types across methods.

Some methods return Ctx (e.g., Status, Type) while others return error. Consider standardizing the return types for better consistency and predictability.

For example:
-func (r *DefaultRes) Status(status int) Ctx {
+func (r *DefaultRes) Status(status int) error {
   return r.ctx.Status(status)
}

-func (r *DefaultRes) Type(extension string, charset ...string) Ctx {
+func (r *DefaultRes) Type(extension string, charset ...string) error {
   return r.ctx.Type(extension, charset...)
}

req.go

coderabbitai

Actionable comments posted: 2

♻️ Duplicate comments (1)

req.go (1)
109-111: ⚠️ Potential issue

Remove unused parameter override from Path method.

The override parameter is declared but never used in the Path method.

Apply this diff:
-func (r *DefaultReq) Path(override ...string) string {
+func (r *DefaultReq) Path() string {
 	return r.ctx.Path()
 }
🧰 Tools

🪛 GitHub Check: codecov/patch

[warning] 109-110: req.go#L109-L110
Added lines #L109 - L110 were not covered by tests

🧹 Nitpick comments (1)

res.go (1)

1-119: Add unit tests for the response API methods.

The static analysis indicates that the new response API methods lack test coverage. This is critical for ensuring the delegation pattern works correctly and maintaining reliability during future changes.

Would you like me to help generate comprehensive unit tests for these methods?

📜 Review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between 0598cb0 and bb91f32.

📒 Files selected for processing (4)

req.go (1 hunks)
req_interface_gen.go (1 hunks)
res.go (1 hunks)
res_interface_gen.go (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

req_interface_gen.go
res_interface_gen.go