Open coderabbitai[bot] opened 1 day ago
code from the request id middleware adjustement https://github.com/gofiber/fiber/pull/3200/files
@ReneWerner87 We need to carefully discuss which middleware need to add requestID, because from the routing to the control layer to the service layer in this process, I see that most of the Go developers will choose to control layer Fiber's Ctx into UserContext, because Fiber as a web framework its function in the whole architecture in the control layer has ended, the service layer will be conducted specific business processing, in the service layer business more concurrent security context, and fiber context is not concurrent security, and requestId in the microservice link tracking is very important to locate the problem, so here will be proposed to increase the request mw UserContext requestID.
The following is the GPT's answer for reference. Fiber's context (ctx) is not inherently thread-safe. Each context instance is tied to a specific request and should only be used within that request's handler goroutine. If you need to access ctx data from different goroutines, you should.
Example of what to avoid.
app.Get(“/”, func(c *fiber.Ctx) error {
go func() {
// UNSAFE: accessing ctx from different goroutine
data := c.Query(“someData”)
}()
return nil
})
Safe approach.
app.Get(“/”, func(c *fiber.Ctx) error {
data := c.Query(“someData”) // Get data first
go func(safeData string) {
// SAFE: using copied data
process(safeData)
}(data)
return nil
})
@JIeJaitt This is for using context.Context
, not fasthttp.RequestCtx
.
Based on the discussion in Issue #3175, we need to extend context support to other middlewares for consistency.
Middlewares to update:
This will ensure that relevant context can be passed through the
context.Context
in these middlewares.Requester: @ReneWerner87