Bug 2735: The Auto-Nav Bug That Wouldn't Reproduce, Until It Did

TL;DR

• Auto-navigation stopped firing after a user logs out and back in, but only after a user switch.
• Ruled out storage: the app’s MMKV container is separate from user scope and persists across reloads and full closes.
• Ruled out the hook: useAppStateTransition fires reliably whether or not the user has a vision.
• What fixed it was initialising the app state manager universally in app.tsx.
• The fix works and violates separation of concerns, so it’s a lead rather than a resolution.

Bug 2735: after a user logs out and logs back in, auto-navigation doesn’t trigger. One of those days where my brain was playing ping-pong.

Failing to reproduce it

The bug manifested once, after a user switch, and then refused to come back. That framing mattered — “only after switching users” is a much narrower claim than “after logging back in”, and it’s what eventually pointed somewhere useful.

Theory one: signing out dereferences local storage. Our auth context destroys user data through a singleton facade around RNMMKV. On logout it should clear the stored user ID, and I suspected the underlying MMKV instance lingers even after we dereference the facade — which would break the stored timestamp the app needs when it goes inactive.

Wrong. The app creates its own storage container, separate from user scope, so signing out doesn’t touch it.

Theory two: storage isn’t persisting. Set some MMKV values, reload, close the app entirely, reopen. All still there. Can’t argue with that.

Theory three: useAppStateTransition isn’t consumed properly. Also wrong. Transitions fire reliably whether or not the user has a vision, and the app state change handler registers consistently every time.

At that point every component of my theory checked out and I couldn’t trigger the original failure at all. It went back into the backlog of unresolved mysteries.

What actually moved it

Coming back to it, I stopped asking whether the pieces work and started asking when they get set up.

App state transition management is instantiated during specific lifecycle events. In a user-switch scenario, that instantiation is plausibly skipped — the app never fully tears down, so whatever hook registers the handler may not run again. Every individual piece works; the sequencing is what differs.

So I initialised it universally in app.tsx. Hacky, deliberately, as a probe rather than a fix.

Then I logged in and out repeatedly, switching users, watching whether session validation prompted auto-navigation. It did, consistently. Smooth transitions, no reproduction of the bug.

Why I’m not calling this fixed

Initialising in the root component works because it guarantees the handler exists before anything can need it. That’s a sledgehammer. It puts lifecycle setup in a place that has no business owning it, and it papers over the real question of why user switching skips the normal path.

The honest state: I have a workaround that holds, a much better theory than I had this morning, and an architectural smell to clean up. Sessions switching should trigger all the necessary hooks on their own, and until they do, this fix is load-bearing in a way I don’t love.