Uncaught serializeUser exception and session growth in Passport session handling

Passport session management relies on serializeUser and deserializeUser to store and reconstruct user identity across requests. Research notes indicate potential retention of session data when serializeUser throws an uncaught exception, with behavior varying by Passport version and session store implementation.

The goal is to clarify the documented cleanup guarantees for session objects under serialization failures, and how the internal request.user property is handled when deserializeUser throws synchronously. Version assumptions for Passport 0.4.x, 0.5.x and 0.6.x are relevant, as is the distinction between in-memory and external stores.

Does Passport guarantee removal of the partially created session entry when serializeUser fails? Is request.user cleared when deserializeUser throws synchronously during request processing? How does session regeneration behave when authentication fails mid-process across these versions?