Walkthrough

A new public method OverrideParam is added to the Ctx interface and DefaultCtx implementation to allow modifying route parameter values. The method normalizes wildcard tokens and updates corresponding parameters with case-sensitive and case-insensitive lookup support. Comprehensive tests and API documentation are included.

Changes

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

📒 Documentation

Suggested reviewers

• sixcolors
• efectn
• ReneWerner87
• gaby

Poem

🐰 A param in flight, now we can rewrite!
Override the value, set it just right,
Wildcards and names, both handled with care,
Case-sensitive too—a feature so fair! ✨

Pre-merge checks and finishing touches

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.

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

Summary of Changes

Hello @TheAspectDev, 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 enhances the DefaultCtx functionality by adding an UpdateParam method, enabling the dynamic modification of route parameters during request processing. This feature provides greater flexibility for developers to manipulate request parameters on the fly, aligning with patterns seen in frameworks like Express.js. The changes are thoroughly tested with new unit tests and benchmarks to ensure correctness and optimal performance.

Highlights

• New UpdateParam Method: Introduced UpdateParam to DefaultCtx allowing dynamic modification of route parameters, mirroring Express.js req.params behavior.
• Parameter Override Logic: The UpdateParam method can override existing route parameters and gracefully ignores attempts to update non-existent parameters.
• Nil Router Handling: Ensured UpdateParam behaves correctly when no route is matched (i.e., c.route is nil), preventing errors.
• Comprehensive Testing: Added new unit tests to validate the UpdateParam method's behavior, covering parameter overriding, ignoring non-existent parameters, and nil router scenarios.
• Performance Benchmarking: Included benchmarks for UpdateParam to measure and track its performance.
• Documentation Update: The Ctx interface and API documentation have been updated to reflect the new UpdateParam method, including its signature and an example.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

/gemini summary

Summary of Changes

This pull request introduces a new UpdateParam method to the DefaultCtx context, allowing developers to dynamically modify route parameters during request processing. This enhancement provides greater flexibility in handling request parameters, drawing inspiration from frameworks like Express.js, and is supported by new tests, benchmarks, and updated documentation to ensure its correctness and performance.

Highlights

• New UpdateParam Method: A new UpdateParam method has been implemented in DefaultCtx to allow dynamic modification of route parameter values by name, mirroring Express.js req.params behavior.
• Parameter Override Logic: The UpdateParam method is designed to override existing route parameters while gracefully ignoring attempts to update non-existent parameters and handling scenarios where no route is matched (nil router).
• Comprehensive Testing and Benchmarking: New unit tests have been added to validate the UpdateParam method's behavior across various scenarios, including overriding, ignoring non-existent parameters, and nil router handling. A benchmark has also been included to measure its performance.
• Documentation Update: The Ctx interface and API documentation (docs/api/ctx.md) have been updated to reflect the new UpdateParam method, including its signature and an example.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

/gemini review

Actionable comments posted: 0

🧹 Nitpick comments (3)

ctx_test.go (1)> 8119-8140: Consider asserting the final param value after the benchmark loop

To mirror other benchmarks in this file and catch regressions in UpdateParam, you can add a quick post‑loop check that the parameter was actually updated; this won’t materially affect timing.

Proposed post-loop assertion

 func Benchmark_Ctx_UpdateParam(b *testing.B) {
@@
 	c.setMatched(true)
 
 	b.ReportAllocs()
 	b.ResetTimer()
 	for b.Loop() {
 		c.UpdateParam("name", "changed")
 	}
+
+	// Verify that UpdateParam actually updated the value
+	require.Equal(b, "changed", c.Params("name"))
 }

router_test.go (1)> 11-11: Route param max-exceed test is good; you may want to assert the panic message too

The new test correctly forces maxParams+1 parameters and ensures register panics, and the fmt import is scoped to that usage. If you want the test to lock in the formatted error (count, limit, and path), you could switch to require.PanicsWithValue (or inspect recover() inside the closure) and assert that the message contains the expected details.
Also applies to: 736-750

ctx.go (1)> 386-419: Implementation is correct, but outdated comments should be removed.

The core logic is sound:

• Uses c.Matched() to verify route existence
• Correctly normalizes wildcard tokens (* → *1, + → +1)
• Properly handles case-sensitive and case-insensitive parameter matching using utils.EqualFold

However, the comments on lines 402 and 413 stating "Prevent out-of-bounds access if route params exceed allocated values" are now outdated. With the new validation at route registration (router.go:550-552), routes cannot exceed maxParams, so the iteration over c.route.Params will never go out of bounds. These comments should be removed to avoid confusion.

🔎 Suggested cleanup

 	if c.app.config.CaseSensitive {
 		for i, param := range c.route.Params {
-			// Prevent out-of-bounds access if route params exceed allocated values
 			if param == name {
 				c.values[i] = value
 				return
 			}
 		}
 		return
 	}

 	nameBytes := utils.UnsafeBytes(name)
 	for i, param := range c.route.Params {
-		// Prevent out-of-bounds access if route params exceed allocated values
 		if utils.EqualFold(utils.UnsafeBytes(param), nameBytes) {
 			c.values[i] = value
 			return
 		}
 	}

📜 Review details

• 8119-8140: Consider asserting the final param value after the benchmark loop: this is expected behaviour and tested by Test_Ctx_UpdateParam
• Other two changes are acceptable and will be pushed asap

@sixcolors

@TheAspectDev Pls also mention the new functionality with an example in the whats new md file
Otherwise its Kind of hidden for the others and less people will use it

@gaby @sixcolors @efectn
Wdyt about the name?
@coderabbitai pls list possible names for this function
How is the name in expressjs or other rest/http frameworks?

Express.js req.params modify parameter values how to change route parameters

route parameter mutation other web frameworks Koa Hapi Fastify Gin Chi naming conventions

@ReneWerner87 Great question! Let me provide some context and alternatives:

Express.js and JavaScript Frameworks

In Express.js, req.params is simply a mutable object that you can directly modify (e.g., req.params.id = 'newValue'). Express also provides app.param() for preprocessing and normalizing parameter values before route handlers.

Other JavaScript frameworks follow similar patterns:

• Koa: ctx.params (plain object, mutable)
• Hapi: request.params (plain object, mutable)
• Fastify: request.params (plain object, mutable)

Since these expose params as plain objects, there's no dedicated "update method" – you just assign directly.

Go Frameworks

Gin uses c.Param("name") for reading, while Chi uses chi.URLParam(r, "name") as a read accessor.

Possible Alternative Names for Fiber

Given that Fiber uses explicit getter/setter patterns (like Params(key) for reading), here are alternatives for the setter:

1. SetParam – Most common setter naming convention; pairs well with getter pattern
2. ModifyParam – Explicitly indicates mutation of existing values
3. OverrideParam – Emphasizes replacing existing parameter values
4. WriteParam – Clean read/write symmetry with Params()
5. MutateParam – Very explicit about mutation
6. PutParam – HTTP-style verb
7. ChangeParam – Simple and clear

Recommendation

I'd suggest SetParam as it:

• Follows standard getter/setter naming conventions
• Is concise and intuitive
• Pairs naturally with the existing Params(key) getter
• Doesn't over-emphasize the "update vs create" distinction (the method already handles both gracefully)

However, UpdateParam is also perfectly valid and clearly communicates the intent to modify existing route parameters, which aligns with the PR's goal of matching Express.js mutable semantics.

What do you think? @gaby @sixcolors @efectn

Learnt from: ReneWerner87
Repo: gofiber/fiber PR: 2864
File: ctx_test.go:4816-4816
Timestamp: 2024-10-08T19:06:06.583Z
Learning: The `ParamsInt` function's behavior, including handling empty string parameters, will be addressed in future PRs as per ReneWerner87's guidance.

Learnt from: ReneWerner87
Repo: gofiber/fiber PR: 2864
File: ctx_test.go:4816-4816
Timestamp: 2024-07-26T21:00:12.902Z
Learning: The `ParamsInt` function's behavior, including handling empty string parameters, will be addressed in future PRs as per ReneWerner87's guidance.

Learnt from: gaby
Repo: gofiber/fiber PR: 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`.

I like SetParam or OverrideParam

I like SetParam or OverrideParam

• I like OverrideParam.

@sixcolors @TheAspectDev ok with the new name?

Yeah, OverrideParam seems more fitting to the action it does.

@TheAspectDev Pls also mention the new functionality with an example in the whats new md file Otherwise its Kind of hidden for the others and less people will use it

Okay!

@ReneWerner87

Actionable comments posted: 0

🧹 Nitpick comments (1)
📜 Review details

This behavior is expected and tested in Test_Ctx_OverrideParam

@sixcolors @TheAspectDev ok with the new name?

Yes it’s good. Thanks @ReneWerner87

Perfect, merge 🤩

Congrats on merging your first pull request! 🎉 We here at Fiber are proud of you! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord