Prefork mode state isolation and request-scoped cleanup in Fiber v3

Answer first

Fiber v3 does not provide a Prefork-specific cleanup callback or deterministic finalizer for request-scoped storage. Cleanup of request-scoped values is the normal Go handler lifetime: ctx.Locals lives on *fiber.Ctx for the duration of the current request/handler goroutine and becomes eligible for garbage collection once the handler returns. Prefork does not change that lifetime.

App-level values are not shared live across Prefork workers. Prefork creates separate OS processes from a shared listener. After fork, process memory is copy-on-write, so each worker has its own independent copy of the address space. Mutations in one worker are not visible to others unless stored in an external shared store.

Whether an App-level value is initialized once per worker is an application sequencing concern, not a documented Fiber isolation guarantee. State built before the listener starts is fork-copied into each worker image. State initialized after fork or lazily on first use is independent per worker.

Confirmed facts vs likely behavior

Confirmed:

• Prefork spawns multiple OS worker processes behind a listener.
• ctx.Locals is request-scoped to the current *fiber.Ctx and handler goroutine.
• Fork semantics give copy-on-write memory isolation between workers.
• Graceful shutdown stops accepting new connections and lets in-flight requests finish; it does not add per-request Locals cleanup beyond normal handler return.

Likely but version-sensitive:

• Fiber v3 reorganizes router and context APIs and enforces stricter context usage relative to v2, but Fiber does not document a Prefork-specific cleanup timing for Locals or App-level after-fork hooks.
• App-level initialization timing is determined by where you build state relative to app.Listen with Prefork enabled. Before listen = fork-copied baseline per worker. After fork / lazy = per-worker independent initialization.

How to structure middleware to avoid cross-request leakage under Prefork

1. Never store *fiber.Ctx, ctx.Locals values, or request-scoped pointers in App-level or global variables.
2. Do not spawn goroutines that outlive the handler and touch request state. If background work is needed, copy only serializable data out of the request.
3. Keep App-level state immutable after worker start, or treat it as worker-local only. For mutable shared state across workers, use an external store or IPC, not App variables.
4. Close per-request resources with defer inside the same handler: DB rows, files, timers. Do not rely on worker shutdown for per-request cleanup.

Verification steps for this case

• Run with Prefork and ≥2 workers. Return os.Getpid() and a per-worker counter incremented on each request. Counters should be per-pid, not cumulative across workers.
• Send concurrent requests with unique ctx.Locals keys and assert the same Locals value is never observed in a different request.
• Confirm in your entrypoint whether App-level state is constructed before or after Prefork starts. This changes whether you get a fork-copied baseline or per-worker initialization.

One missing diagnostic detail that changes the recommendation: is your App-level state constructed before app.Listen is called with Prefork enabled, or is it initialized lazily inside middleware/handler after the fork? Pre-listen construction means fork-copied baseline per worker; post-fork/lazy means per-worker independent state.