🐛 [Bug]: `fiber migrate --to v3` converts `c.BodyParser(c)` to `c.Bind().Body(c)` causing OOM

[kacpi52]

Bug Description

The fiber migrate tool mechanically converts the v2 pattern c.BodyParser(c) to c.Bind().Body(c) during migration to v3. While syntactically valid, the result causes runaway memory allocation in a single goroutine, leading to OOM within seconds of the handler being hit.

example logs :
2026/05/28 13:55:11 MEM: alloc=2MB sys=18MB numGC=3 goroutines=37
2026/05/28 13:55:12 MEM: alloc=2MB sys=18MB numGC=3 goroutines=37
2026/05/28 13:55:13 MEM: alloc=2MB sys=18MB numGC=3 goroutines=37
2026/05/28 13:55:14 MEM: alloc=1283MB sys=1367MB numGC=11 goroutines=37
2026/05/28 13:55:15 MEM: alloc=2964MB sys=3115MB numGC=13 goroutines=37
2026/05/28 13:55:16 MEM: alloc=4774MB sys=4927MB numGC=13 goroutines=37
2026/05/28 13:55:17 MEM: alloc=6379MB sys=6538MB numGC=14 goroutines=36
2026/05/28 13:55:18 MEM: alloc=7993MB sys=8157MB numGC=14 goroutines=34
2026/05/28 13:55:19 MEM: alloc=9483MB sys=9775MB numGC=14 goroutines=34
2026/05/28 13:55:20 MEM: alloc=10986MB sys=11310MB numGC=14 goroutines=32

How to Reproduce

Minimal reproduction:

1. Create a v2 Fiber project containing a handler that mistakenly passes c to BodyParser:

// v2
app.Post("/leak", func(c *fiber.Ctx) error {
    if err := c.BodyParser(c); err != nil {
        return err
    }
    return c.SendStatus(200)
})

In v2 this is a latent bug but does not crash — most requests pass through without obvious symptoms.

2. Migrate using the official tool:
   go install github.com/gofiber/cli/fiber@latest
   fiber migrate --to v3.0.0
3. The migrator silently rewrites the handler to:

// v3 — silently produced by migrate tool
app.Post("/leak", func(c fiber.Ctx) error {
    if err := c.Bind().Body(c); err != nil {
        return err
    }
    return c.SendStatus(200)
})

4. Send any POST to /leak:

Expected Behavior

• The migration tool detects c.BodyParser(c) (BodyParser called with the context itself as argument) and refuses to migrate it automatically, emitting a warning that the call should be rewritten manually.
• Or the migration tool rewrites it to a safe no-op equivalent and emits a TODO comment.

At minimum, this transformation should not silently introduce an OOM vector into production code that previously appeared to work.

Fiber Version

v3.3.0

Code Snippet (optional)

// v2
app.Post("/leak", func(c *fiber.Ctx) error {
    if err := c.BodyParser(c); err != nil {
        return err
    }
    return c.SendStatus(200)
})

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.

[welcome]

Thanks for opening your first issue here! 🎉 Be sure to follow the issue template! If you need help or want to chat with us, join us on Discord https://gofiber.io/discord

[ReneWerner87]

thx for the report

[ReneWerner87]

@kacpi52
Am I correct in thinking that the bug report isn't referring to the Migrator tool but to Binder itself?

When does the OOM occur, during migration or when running the migrated application?

If it's the latter, we need to move the issue to the core
Because it has the same effect whether a person or the CLI performs the migration.
According to the output, it migrated correctly.

If that’s the case, we need to know the input and require a minimal reproducible example with the sample input.

[ReneWerner87]

@kacpi52 can you share an example of the struct and data from the request