🐛 [Bug]: Appending handlers screws up routing

[JonasDoe]

Bug Description

If I append multiple middlewares to slices in this manner: middleware := append([]fiber.Handler{f, f}, f), and re-use this middleware for different routes (with different handlers), the routing won't work correctly but will always take the last registered endpoint.

How to Reproduce

1. Just run the example code below to start the faulty server.
2. Invoke http://localhost:12345/p1
3. You'll see "p2" printed, instead of "p1". Changing the p2 endpoint to the POST method won't change this faulty behavior either.
4. Remove any of the fs from the middleware, the expected "p1" willl be printed.

Expected Behavior

I'ld expect the proper route to be taken, i.e. "p1" being printed when I invoke the p1 endpoint.

Fiber Version

v2.52.4
v3.0.0-beta.2

Code Snippet (optional)

For v2:

package main

import (
	"fmt"
	"github.com/gofiber/fiber/v2"
)

func main() {
	router := fiber.New()
	f := func(ctx *fiber.Ctx) error { return ctx.Next() } // inlining those won't change the behavior
	middleware := append([]fiber.Handler{f, f}, f)
	router.Get("p1", append(middleware, func(ctx *fiber.Ctx) error { fmt.Print("p1"); return nil })...)
	router.Get("p2", append(middleware, func(ctx *fiber.Ctx) error { fmt.Print("p2"); return nil })...)
	_ = router.Listen(fmt.Sprintf(":%d", 12345))
}

For v3:

package main

import (
	"fmt"
	"github.com/gofiber/fiber/v3"
)

func main() {
	router := fiber.New()
	f := func(ctx fiber.Ctx) error { return ctx.Next() } // inlining those won't change the behavior
	middleware := append([]fiber.Handler{f, f}, f)
	router.Get("p1", func(ctx fiber.Ctx) error { fmt.Print("p1"); return nil }, middleware...)
	router.Get("p2", func(ctx fiber.Ctx) error { fmt.Print("p2"); return nil }, middleware...)
	_ = router.Listen(fmt.Sprintf(":%d", 12345))
}

Checklist:

• I agree to follow Fiber's Code of Conduct.
• I have checked for existing issues that describe my problem prior to opening this one.
• I understand that improperly formatted bug reports may be closed without explanation.

[ReneWerner87]

@JonasDoe
append change the original array.

[JonasDoe]

@JonasDoe append change the original array. That has nothing to do with our routing.

Woot, this would explain the bug, but would destroy my understanding of slices.
That said, I cannot reproduce this "changing of the original array": In this example, s1 remains unchanged - what am I missing?

Edit: Found an explanation. Basically, I was filling up the initial slices up to its capacity. Well, this is really stunning. Thanks for the heads up!