middleware/logger/logger.go (1)

100-101: TemplateChain / LogFuncChain are written into the pooled Data on every request — confirm no consumer mutates them.

Both fields share the same underlying slices across all requests. The default logger now passes them straight to logtemplate.ExecuteChains, which only reads, so this is safe today. Worth a brief note in Data's GoDoc that custom LoggerFunc implementations must treat these slices as read-only, since mutation would corrupt every subsequent request.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@middleware/logger/logger.go` around lines 100 - 101, The Data struct's
TemplateChain and LogFuncChain fields are shared pooled slices and must be
treated as read-only by consumers; update the GoDoc for type Data to explicitly
state that TemplateChain and LogFuncChain are shared across requests and must
not be mutated by custom LoggerFunc implementations (they may only
read/iterate), and add a short comment near the assignment site (where
data.TemplateChain and data.LogFuncChain are set) referencing
logtemplate.ExecuteChains as the current reader to make the expectation clear.

log/context.go (1)

35-48: Consider returning the build error instead of panicking.

SetContextTemplate panics if logtemplate.Build rejects the format string. For a library setter API this is unusual — callers typically expect Set* functions to be infallible or to return an error. Panicking forces users to either validate the format themselves or wrap calls in recover(). Since this is a brand-new API, the signature change is essentially free.

♻️ Suggested change to return an error

-// SetContextTemplate configures contextual fields rendered by WithContext for Fiber's default logger.
-func SetContextTemplate(config ContextConfig) {
+// SetContextTemplate configures contextual fields rendered by WithContext for Fiber's default logger.
+// It returns an error if config.Format cannot be parsed.
+func SetContextTemplate(config ContextConfig) error {
 	if config.Format == "" {
 		contextTemplate.Store(nil)
-		return
+		return nil
 	}
 
 	tmpl, err := logtemplate.Build[context.Context, ContextData](config.Format, createContextTagMap(config.CustomTags))
 	if err != nil {
-		panic(err)
+		return err
 	}
 
 	contextTemplate.Store(tmpl)
+	return nil
 }

If a panicking variant is still desirable, consider a MustSetContextTemplate wrapper following the standard library text/template.Must convention.

Please confirm whether the panic-on-error semantics is intentional (e.g., to surface misconfiguration loudly at startup) and double-check whether any of the new docs/examples in docs/api/log.md already advertise this signature, since changing it would require a docs update.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@log/context.go` around lines 35 - 48, Change SetContextTemplate to return an
error instead of panicking: call logtemplate.Build inside SetContextTemplate,
and if it returns an error, return that error to the caller; on success store
the template into contextTemplate via contextTemplate.Store(tmpl) and return
nil. Keep the current panic behavior as an optional MustSetContextTemplate
wrapper (e.g., MustSetContextTemplate calls SetContextTemplate and panics on
non-nil error) if you want a loud-startup variant. Update references to
SetContextTemplate callers to handle the returned error.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes